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1 SYSTEM AND METHOD FOR MULTIPLE LEVEL ARCHITECTURE BY USE OF 

2 ABSTRACT APPLICATION NOTATION 

3 

4 The present invention relates to methods and systems for the transformation of languages 

5 and computer platforms. 
6 

7 BACKGROUND OF THE INVENTION 

8 Software capabilities and requirements are rapidly advancing in the present field of 

9 computer technology. Companies all over the world desire robust and versatile software 

10 solutions to help their businesses expand and excel. However, in spite of overwhelming demand, 

1 1 many companies find that the available software solutions are limited in selection, and that the 

12 software solutions are generally developed to support only one programming platform. 

O 

y|3 Accordingly, many companies are struggling with a wide variety of choices for client platforms, 

;i^4 transaction servers, and data base systems, while at the same time facing the challenge of 

^ill5 integrating them all into one working solution. In general, software applications interact with 

j;l|6 objects, which are a collection of procedures defining a procedural logic of the application. It is 

4*7 desired that these objects can be used by multiple applications and systems, however this ability 

1338 is typically limited because objects tend to be designed as platform specific. Accordingly, an 

object designed for one application that functions on one platform may not be easily accessible 

'| f p by another software application written for a different platform. Therefore, this limitation has 

|24 made the sharing of objects across different systems and platforms difficult, thus making the 

22 sharing objects over an Internet environment problematic. 
23 

24 In the past, many programming languages and applications have been developed for use 

25 in computation. Early languages were often very closely tied to the physical hardware of the 

26 device being programmed. As the complexity of software grew, it became advantageous to 

27 develop systems which abstracted away most of this complexity from the user. Accordingly, the 

28 need for adaptability in software applications has intensified in the past few years, as a result of 

29 the growth of the Internet, from a large number of companies attempting to extend their business 

30 practices to the World Wide Web. Companies of today are concerned with providing highly 
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1 distributed software applications that are fully accessible over the Internet. Accordingly, users of 

2 the company services expect to access their data from any number of devices such as wireless 

3 hand held devices, web browsers, and their desktops, regardless of the operating system they are 

4 implementing. Accordingly, software programmers today must often develop and customize the 

5 same application several times in a variety languages to work in these different environments. 

6 Attempts have been made to run the same program somewhat modified for different platforms, 

7 however this typically results in a poor output as the code is not optimized to the constraints of 

8 each and every target machine to which it is applied. For example, the desire to run a rich desk 

9 top application but on a light weight hand held device. 

10 

11 A further problem is that many companies wish to adapt their existing software systems, 

12 such as Legacy applications with character based interfaces and hardware, to scalable Internet 
k iB enabled modern systems. Accordingly, shifting from Legacy based applications typically 

Itfi involves choosing between continuing to develop new code on an expensive antiquated system, 
or getting rid of existing equipment and purchasing new adaptable hardware and corresponding 
software applications. 

S] 

In view of the above discussed application constraints, there have been several 

cn 

\W approaches in the past used to simplify application development for multiple platforms. The 

jgjb earliest attempts were centered around a preprocessor, which is a straight forward device that 

SM takes an input file written in a specific software language, containing not only language specific 

22 statements but also preprocessor directives. The directives helped the user to create macros or 

23 short hand phrases which represented more complicated constructs. In turn, more complicated 

24 directives were developed to allow the porting of applications from one computer system to 

25 another. However, the main draw back to preprocessors is that the source code is interspersed 

26 with preprocessor directives, which becomes more complicated to read. In addition, the 

27 underlying complexities of the different platforms, while dealt with, are no way hidden from the 

28 user, thereby requiring the user to determine which portions of their code must be modified for 

29 the various selected platforms. This can be a labor intensive and accordingly costly procedure. 
30 
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1 A second generation of software tools was developed to isolate the user from details of 

2 the underlying architecture. The second generation tools were more intelligent allowing the user 

3 to specify segments of their code in a language independent format. The source code was then 

4 passed through a preprocessor where dependent code was added to the source file, examples of 

5 which include SQL pre-compilers. However, pre-compilers are generally limited to a section of 

6 the source code which is capable of being written in the independent format. This process helps 

7 to remove the underlying details of language specific libraries but does not substantially reduce 

8 the volume of code necessary to write a given application. 
9 

10 A further attempted solution to the transport of an application to multiple platforms is 

1 1 translators. Many translation routines exist which allow one language to be converted to another, 

12 which fall into the two broad categories of natural language systems and artificial language 
,13 systems. However, m natural language systems exact translation can be difficult to obtain and 

4-4 therefore probabilities and pattern matching must be used. Although, this approach is 

M 

>jB5 unacceptable for computer languages as the translations must be deterministic and accurate. 

\IS Accordingly, artificial language systems have focused on translation from one known language 

'17 to another by a well understood medium. The construction of translators, so that language 
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specific code is modularized and reusable, is generally accomplished by parsing the input 

p program and constructing a single or series of abstract syntax trees. The syntax trees represent a 

-2b language independent view of the operations at a low level. The translation process involves 

□ 

|2i first manipulation of this representation and then reversal of the process, which is generating the 

22 translated code from the syntax tree. One example of this process is taught by US Patent No. 

23 6,031,993 by Andrews et al. This patent describes a method, system, and apparatus for 

24 translating one computer language to another using a doubly routed tree data structure. The 

25 structure is a combination of two sets of hierarchical related objects sharing a common set of 

26 leaves. The object of the patent is to provide a method and apparatus for automatically 

27 translating the source code from one high level computer language to the source code of another 

28 language. However, the construction of the routed tree structures is performed on a source code 

29 by source code basis. This can be a relatively expensive approach as the code must be broken 

30 down and then re-assembled. A second disadvantage is that it is difficult for humans in 
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1 understanding the abstract representation, wherein the interpretation of a single line of code 

2 could involve numerous nodes. 
3 

4 A more recent approach to solving portability concerns has been the advent of virtual 

5 machine based architecture, wherein virtual instructions are executed by converting them into 

6 real instructions which can be executed on the actual machine. Several such architecture exist 

7 today, from interpreting bit codes at a hardware level to application servers which dynamically 

8 re-interpret their source documents depending upon the calling process requirements. However, 

9 one disadvantage to these interpretative systems is that substantial performance penalties are 

10 imposed by them as each time the system is accessed, the translation of the calls must be done 

1 1 anew. This has to a certain extent been mitigated by the use of cashing architectures but 

12 performance penalties still remain. 

'•1<4 It is an object of the present invention to obviate or mitigate some of the above presented 

*il|5 disadvantages. 



W7 SUMMARY OF THE INVENTION 



j3|8 According to the present invention there is provided a multi-tier application system for 

eh 

^9 generating a central application for deployment on a predetermined combination of selected 



components. The system comprises: 

j2,l a) an abstract notation description file to contain data for the central application; 

22 b) an editor for entering a selected set of input parameters to provide the data; and 

23 c) an application generator for transforming the data from the abstract notation to a 

24 selected platform notation corresponding to the selected components, the selected 

25 notation contained in the central application; 

26 wherein the deployment of the central application, monitors the communication of 

27 component data between the selected components. 
28 
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According to a further aspect of the present invention there is provided a method for 
generating a central application for deployment on a predetermined combination of components 
selected from a multi-tier environment. The method comprises the steps of: 

a) selecting input parameters for representing data for the central application; 

b) combining the input parameters for producing and abstract notation description 
file comprising the data; 

c) transforming the data from the abstract notation to a selected platform notation 
corresponding to the selected components; and 

d) generating the central application containing the platform notation; 

wherein deployment of the central application monitors the communication of component 
data between the selected components. 



According to a still further aspect of the present invention there is provided a computer 
program product for generating a central application module for deployment on a predetermined 
combination of selected components. The product comprises: 

a) a computer readable medium; 

b) an abstract notation description module stored on said computer readable medium 
for containing data for the central application module; 

c) an editor module coupled to the description module for entering a selected set of 
input parameters to provide the data; 

d) an application generator module coupled to said description module for 
transforming the data from the abstract notation to a selected platform notation 
corresponding to the selected components; and 

e) the central application module coupled to the generator module for receiving the 
selected platform notation; 

wherein the deployment of the central application module monitors the communication of 
component data between the selected components. 
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1 BRIEF DESCRIPTION OF THE DRAWINGS 

2 These and other features of the preferred embodiments of the invention will become more 

3 apparent in the following detailed description in which reference is made to the appended 

4 drawings by way of example only, wherein: 

5 Figure 1 is a block diagram for an abstract notation architecture system; 

6 Figure 2 is a block diagram of the application development system of Figure 1 ; 

7 Figure 3 is a diagram of parameters of the system of Figure 2; 

8 Figure 4 is a middle ware component of Figure 1; 

9 Figure 5 is a further middle ware component of Figure 1 ; 

10 Figure 6 is a sample interface of the system of Figure 1; 

1 1 Figure 7 is a block diagram of custom querying of Figure 1 ; 

12 Figure 8a, b, c, d, e, f is an example Application Editor of the system of Figure 1; 

O 

•i|3 Figure 9 is a further example of the Editor of Figure 8; 

^4 Figure 10 is an implementation of an application of Figure 2; 

^5 Figure 11 is an example deployment of the system of Figure 1; 

|;|6 Figure 12 is a block diagram of the operation of the system of Figure 2; and 

47 Figure 13 is a further embodiment of the system of Figure 2. 

□8 

i;n 

|.19 DESCRIPTION OF THE PREFERRED EMBODIMENTS 

tfo 

U 

p21 Referring to Figure 1, a general n-tier application system 10 consists of a first tier 14 

22 comprising a client side system or user interface 18 for interacting with an end tier system 16, in 

23 this case a third tier, comprising a data source 20a, b for the storage and retrieval of data. The 

24 user interface tier 14 is the visible part of the system 10 that can be manipulated by the user, 

25 generally involving the entering and displaying of data. The user can thereby manipulate multi 

26 media files through the interface 18, and can also upload, download, view, or otherwise 

27 manipulate the files contained in the databases 20a, b. Accordingly, the end tier 16 can be used 

28 to store user critical data on a long term basis for intermittent or continuous retrieval by the user 

29 through the user interface tier 14. Database access or user interface devices 18 of the tier 14 can 

30 include various data communication devices, such as but not limited to desktops 18a, applets 
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1 18b, 18d, wireless hand held devices 18c, mobile computers, pagers, and other PDAs for 

2 accessing the data sources 20a, 20b located in the end tier 16. It should be noted that each of the 

3 access devices 18 uses a corresponding device platform or software 19a, b, c, d for coordinating 

4 the access of the device or user interface 18a, b, c, d with the selected data source 20a, 20b. The 

5 data sources 20a, 20b each use a corresponding communication protocol 21a, 21b for 

6 coordinating the entering and retrieval of their data through a network 22 accessible by the first 

7 tier 14. The network 22 can be comprised of local area networks or global area networks such as 

8 the Internet. Examples of some of the networks 22 can include synchronous optical networks 

9 (SONET), synchronous digital hierarchy (SDH), a synchronous transfer mode (ATM) networks, 

10 microwave and antenna bay stations, satellite networks, and networks comprising a mixture of 

1 1 these technologies. Furthermore, the networks 22 can include such things as routers, or other 

12 interconnected segments that range from copper wire to fiber optic cable to microwave links. 

!^4 The application system 10 can consist of the two tiers 14, 16 as described above, whereby 

h §5 the network 22 would be essentially a single network using a pass through system 24. This 

B 

i||6 system 24 can provide direct data architecture to the system 1 0 to help provide high speed data 

?, 17 access with reduced system 10 complexity and cost. However, a middle tier 26 can be added to 

ft*8 the system 10 for providing pre-determined business logic and addressing security and scalability 

J,i9 concerns of the system 10. Accordingly, the middle tier 26 can be used to focus on the 

j$0 programming of business logic and to provide for scalability and security requires as the system 

U 

l'21 10 is adapted to changing needs. One subset of the middle tier 26 is the pass through 

22 architecture 24 for implementing a two tier 14-16 application model 10. Other components in 

23 the middle tier 26 can include middle ware applications or servers 28a, b, which can include such 

24 as but not limited to a Component Object Model (COM) and Enterprise Java Beans (EJB). 

25 These middle ware components 28a, b function by helping to hide details of running multiple 

26 transactions from the first tier 14, as well as managing and pooling resources to address 

27 performance issues, such as scalability, dynamic load balancing, and failover capabilities. 

28 Accordingly, the middle ware components 28a, b can scale the ability of the system 10 to meet 

29 growing demands, distribute and balance processing capabilities between servers, and reroute 

30 capabilities should selected servers cease to function. The middle tier 26 is situated between two 
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1 networks 22 to facilitate the implementation of the middle ware processes between the first tier 

2 14 and end tier 16. It should be noted that each of the middle tier 26 components 24, 28a, b 

3 includes a selected platform or software 25, 29a, 29b for coordinating the distribution of the data 

4 20a, b from the end tier 16 to the device 18 of the first tier 14. It should be noted that the 

5 platforms 19a, b, c, d, 21a, b, 25, and 29a, b can use differing languages and protocol structures. 
6 

7 The various platform components 19a, b, c, d, 21a, b, 25, and 29a, b are provided by a 

8 central platform application 30, which is generated by an application development system 12. 

9 The system 12 can generate the application 30 for a variety of platforms, such as a series of 

10 graphical user interfaces connected to selected databases 20a, b. The central application 30 can 

1 1 contain a series of sub-applications 32, 34, 36 which may or may not be in the same 

.12 programming language or customized for the same software platform or common hardware 

%JB3 systems 18, 28, 20, thereby helping to provide an end-to-end n-tier application 30. Accordingly, 

^4 the central application 30 provides the series of sub-applications 32, 34, 36 to be deployed on 

!*¥5 various tiers 14, 16, 26 for providing support for a selected combination of components 

fM6 contained in the tiers 14, 16, 26, which can be used by a company to integrate the selected 

s 'l7 components from the tiers 14, 16, 26 into one working solution on a variety of platforms. The 

;i ? 8 sub-applications 32, 34, 36 are developed to provide the platforms 21a, b, 25, 29a, b, and 19a, b, 

M'9 c, d respectively. The system 12 contains a central or abstract application description file 38 

|*jo constructed using a series of input parameters 40, which is then directed into an application 

'il generator 42, which operates on a series of selected inputs 44 containing particulars about the 

22 selected combination of components from the tiers 14, 16, 26 of the system 10. The file 38 can 

23 represent an abstract declaration of a graphical user interface for deployment on the device 18. 

24 The application generator 42 constructs the sub-applications 32, 34, 36 of the central application 

25 platform 30, based on the file 38, thereby providing a predetermined combination of platforms 

26 19a, b, c, d, 21a, b, 25, and 29a, b to facilitate the access of a particular device 18 in tier 14, 

27 through the networks 22 and selected middle ware components 24, 28 of the middle tier 26, 

28 through to the selected databases 20a, b of the end tier 16. Accordingly, the user of a particular 

29 device 18 can then retrieve data from the databases 20a, b review, modify or alter the data, and 

30 then save the changes to the original or alternate selected database 20a, b. It should be noted that 
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1 the generator 42 can generate multiple versions of the file 38 to be applied to a variety of 

2 hardware components in the tiers 14, 16, 26, which is represented by the subprograms 32, 34, 36 

3 of the application 30. Accordingly, the file 38 can be designed to provide a similar look and feel 

4 to the user of various devices 18 across the various hardware software platforms, such as but not 

5 limited to HTML for browser and WAP for hand helds. 
6 

7 Referring to Figure 2, the system 12 is used to generate the central platform application 

8 30 from the abstract language input file 38. The file 38 is then separated across the several 

9 related output files 32, 34, 36, thereby providing database interface platforms 21a,b, application 

10 server platform files 25, 29a, b and user interface platform files 19a, b, c, d. It should be noted 

1 1 that each of these platform files 19a, b, c, d, 21a, b, 25, and 29a, b can be generated in a different 

12 language for a pre-selected deployment combination (see Figure 1 1 and corresponding 

M 

b]l|3 description below). The input parameters 40 to the application file 38 can include designing of 

m 

;Tij4 the application using an application editor 46. The application editor 46 facilitates the input of 

'•§5 declarations into the file 38, as well as previewing previously entered declarations. Preferably, 

f|6 these declarations are stored in an XML format. Furthermore, internationalized strings can be 

h \7 added for functionality in multiple languages. The parameters 40 can include the addition of 

i; 

"88 application business logic 48, including such things as neurons and reports to provide 

pi 

|«19 predetermined functionality to the central application platform 30. The neurons are an 

|3j0 application of event based architecture and can be used to provide architecture that receives 

1*2 1 interprets, and sends messages. The neurons facilitate the specification of arbitrary behaviors for 

22 the platform 30 and are preferably programmed in the XML format. The reports and associated 

23 recursive report style queries of the business logic 48 allow manipulation and access to summary 

24 data, such as reporting via parent/child relationships of the data on the databases 20,a b. 
25 

26 The parameters 44 can include selection of a client or device type 50, which indicates the 

27 device type 18a, b, c, d accordingly. If the device type needs change, thereby requiring a new 

28 interface, the application designer can change the device type independently the other input 

29 parameters 40, 44. The parameters 44 can include a selection of middle tier technology 52, 

30 which facilitates the separation of business logic of the application presiding in the middle tier 26 
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1 from the functionality of the interfaces in the first tier 14. Security, scalability, and reliability 

2 parameters can be designed into the application 30 using these input parameters 52. For 

3 example, the parameter 52 can include specifications for middle tier architectures comprising 

4 EJB and COM, whereby communication with the middle tier 26 can be achieved by using 

5 Simply Object Access Protocols (SOAP) or the pass through parameters 24 can be designed 

6 thereby providing a traditional client-server two-tier architectural model. The parameters 44 can 

7 also include a data source selection 54 or the construction for a customized data source. The data 

8 storage tier 16 is were the data sources 20a, b are located. These databases 20a, b can be an 

9 SQL-compliant database such as the SQL server 7, Sybase adaptive server, or MySQL, as well 
10 as a variety of non-SQL data sources such as flat files, Legacy databases, and XML. 

11 

,,12 Further input parameter 44 can be security requirements 56, which can be based on 

U 

*ifl3 multiple levels of security to provide a predetermined safety level of access to and from the data 

CO 

4]4 sources 20a, b. These parameters 56 can provide high level concurrency control, insulation of 

-f\ 

, r5 databases 20a, b behind corporate firewalls, and query security models for specification of 

ffl6 clearance levels by the client company. Example aspects of the security parameters 56 can 

;! 17 include user level security, web security, data security, and an application service provider (ASP) 

^8 model compliance. Furthermore, industry standard 128 bit or higher Secure Socket Layer (SSL) 

149 encryption can be used. It should be noted that the input of the parameters 40, 44 is not limited 
l.d 

l'20 to the corresponding specific input destinations 38, 42 as described above. Accordingly, 

alternate combinations of input parameters 40, 44 to either the file 38 or the generator 42, or 

22 other combinations thereof can be used by the system 12, depending upon the needs of the 

23 software developer to generate the central platform file 30. Accordingly, once the generator 42 

24 has generated a source code file 30 for a selected component combination of inputs 40,44 

25 representing the entities contained in the tiers 14, 16, 26, the file 30 can then be passed to a 

26 specific language compiler, such as Java or C based, to build an executable code. It should be 

27 noted that this computation stage could also be accommodated by the generator 42, thereby 

28 providing an executable application file 30 for deployment on a selected configuration of the n- 

29 tier application system 10. 
30 
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1 End Tier Systems 

2 The data source selection parameters 54 of the input parameters 44 can be used to define 

3 the particular selected protocol platform 21a, b, as described by the sub-application file 32 of the 

4 central application platform file 30. The data sources 20a 5 b and associated protocols 21a, b can 

5 be selected from any system that can be used to store data from which a predetermined access 

6 level is monitored. The most common types of data sources 20a, b are based on Structure Query 

7 Language (SQL), commonly referred as SQL sources. These sources can include MySQL which 

8 is an open source software that can be used as a readily available database management system, 

9 of which the source code can be download, used, and modified to fit the individual needs of the 

10 user. Another SQL source is SQL Server 7, which can be used to interact with the Microsoft 

1 1 COM objects and other Microsoft based technologies. Sybase is a further data source 20a, b 

12 providing a custom query system typically used in high end database solutions that are designed 

tjjj3 on unique bases. Furthermore, a Freedom Intelligence 20a, b source can be used as a read only 

f : l 

;$4 database solution that can be optimized for executing SQL queries. 

4 

\z-.r. 

|;fi6 In addition to SQL based databases 20a, b, the software development system 12 can also 

17 support a variety of non-SQL sources involving custom query systems, such as but not limited to 

*4?8 flat-files, Legacy databases, and extensible markup language (XML). The flat files can represent 

\ t l9 a database, tree, or network structure such as a single file from which the structure can implicitly 

H 

jjjjJO be rebuilt and modified. Legacy databases 20a, b are commonly known in the art, and typically 

l i 21 represent older and highly customized data sources 20a, b. The system 12 can also utilize XML 

22 as a data source 20a, b by presenting data in a corresponding database structure. 
23 

24 Tradition storage values for databases 20a, b can include numbers and strings. A Binary 

25 Large Object (BLOB) specification, which can be found in SQL 92, further enables the storage 

26 of images, sound, video, and any other form of computer media in a database. Accordingly, the 

27 system 12 can also use a BLOB column to hold an arbitrary string of bits. For example, BLOBs 

28 can be used to store a variety of file types, including multi media files and images, whereby all 

29 these elements are stored in the selected database 20a, b. Accordingly, web pages can be 

30 generated from a series of elements stored on the database 20a, b, including such data as an 
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1 author, price, picture of a book cover, summaries, and customer reviews, such as for an 

2 application 30 for database access system 10 of an online book store. BLOBs can also be used to 

3 build document management systems, such as storing documents in the database 20a, b so that 

4 various individuals can share the materials contained therein. Furthermore, BLOBs can also be 

5 applied to facilitate the storage of CAD diagrams and other imagery data. The use of BLOBs 

6 can also be used to handle BLOB files of unknown types by writing custom entities to view 

7 custom file types by the devices 18 of the system 10. 
8 

9 Security Components 

10 The security requirement parameters 56 of the input parameters 44 can be used to 

1 1 monitor the passing of private and confidential information, such as but not limited to credit card 
.12 numbers, personal addresses, and phone numbers, as monitored by the central application 30 for 

the associated tiers 14, 16, 26 and devices therein of the system 10. The parameters 56 can also 

Qj4 be used to specify security settings for individual fields, tables, and other widgets 60 (see Figure 

?$5 6) used in the interface of the device 18. Since any advanced system 10 could potentially exhibit 

l|}|6 multiple instances of vulnerability, making such systems 10 containing elevated levels of 

17 complexity more prone to security holes. Accordingly, the parameters 56 could be used to 

3 $8 specify user level security details, web security issues, and data security issues. Further to user 

i;n 

S*l>9 level security, passwords could be assigned or login process on the device 18 to distinguish 
M 

different users having different data access levels. Pre-existing queries could be specified to 
I@l execute based on the security clearance granted to each individual user, which would allow the 
22 user to view and modify confidential data on the databases 20a, b while inhibiting other non- 
23 associated users from having the same accessibility. The web security can use 128 bit or higher 

24 Secure Sockets Layer (SSL) encryption to provide secure access to data over the Internet 22. 

25 Accordingly, example applications 30 such as those based on JAVA Server Pages (JSP) platform 

26 can be used in connection with the SSL security standard (see example application as detailed 

27 below). The data security can be used to address such issues as the use of firewalls and the use 

28 of encryption between entities such as database servers 28a, b. 
29 
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1 In addition, the Application Service Provider (ASP) system model can generate specific 

2 security concerns. Accordingly, a User/Company/Application security model can be used to 

3 provide the separation of individual client data from one another. This model can include the 

4 parameters 56 such that each user belongs to a single company and each company has a separate 

5 database 20a, b. When a particular user (belonging to a particular company) logs into an 

6 application using the device 18, the user is given access to the companies database 20a, b as 

7 specified in the central application platform 30. If the company has access to multiple 

8 applications, then the data 20a, b for every application can be shared, facilitating intra operability 

9 between applications. It should be noted that the data security parameters 56 can be used to 

10 specify security requirements in two tier architectural models where the device 18 can access the 

1 1 database 20a, b directly, or in middle or multiple tier architectural models which makes use of 
|Jj2 the middle tier 26 and transaction servers 28a, b. Accordingly, the security features of the 

'ifl3 application platform 30 can reside in any one of the sub-application platform files 32, 34, 36, 



depending upon the desires of the company and design parameters 40, 44 designated by the 



1T5 software designer during construction of the central platform application 30. 

W6 

m 

Bi 17 The security parameters 56 can be setup to determine that once a login has occurred 

n 

^8 through the interface of the device 18, the user name supplied is used to lookup the appropriate 
handle for the user. As well, the application name is used to fetch the appropriate handle for the 

y 

j*20 selected database 20a,b access desired. The user handle and application id can then used to fetch 
the correct group for security permission lookup for each entity listed in the application 30. 

22 Security permissions that are fetched are then applied to all entities in the program 30, 

23 determining what buttons, screens, etc. the user can view, as well as what text fields, grids, etc. 

24 the user can modify. As well, the user handle and the application id are further used to fetch any 

25 customized settings the user may have in the system 10, as defined by the central platform 

26 application 30, such as screen color, etc. 
27 

28 Referring to Figure 3, the parameters 56 can be used to monitor a login and application 

29 access request 110. This request 1 10 would query a Login Database 112, consisting of an 

30 Application Table 1 14 containing a handle Field that references the application 30, the 
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1 application owner Field that holds which company actually has permission to use this application 

2 30, and the application name Field which holds the actual name of the application 30. The 

3 database 112 also contains a Company Table 116 containing a list of all companies which have 

4 data accessible by a particular server 28, the companies handle for locating in other tables, and 

5 who the company owner is, represented by a handle Field for referencing the company for 

6 lookup, a comp owner Field for indicating who the owner of the company is, with respect to a 

7 Users Table 118, and a comp name Field which holds the actual name of the company. The 

8 Users table 118 contains a list of all users 18 who may log into the Application 30 running on the 

9 system 10, their passwords, their handle for locating in other tables, and what company the user 

10 18 belongs to in the following fields, such as a handle Field that references the user 18 for 

1 1 lookup, a user password Field that holds the actual password for the user 1 8, a user company 

12 Field for referencing which company the user 18 belongs to via the company table 116, and a 

U 

tjlB user name Field that holds the actual user name. 

% 

)ih Accordingly, when a user 18 logs into the application 30, their password is checked on 

WS the server 28 under the login database 1 12 in the users table 118. The users table 1 1 8 contains 

m 

17 a reference to the person's company, which is then used to see if the user 18 has permission to 
use that program 30, via the application owner field of the application table 1 14. For instance if 

1:1.9 Company A has this application 30, they don't want the user 18 in their rival Company B to be 

1:1 

able to log into their own separate system 10. Further, the company table 1 16 in the login 

Sfl database 1 12 is also used to determine which security database 120 to use to get the application's 

22 30 permissions. 
23 

24 For example, the security database 120 can include a Company Table 122 containing a 

25 list of all companies which access to the data 20a,b by the selected server 28a,b, their handle for 

26 locating in other tables, and who the company owner is, as described above with reference to 

27 table 116. The database 120 also includes an Entity Table 124 containing a list of all entities 

28 which exist for all applications 30 that have been initialized on the companies system 10. The 

29 entity table 124 contains a handle Field for referencing the entity for lookup by other tables in 

30 the database, an id Field that contains the actual id given to the entity, an application Field that 

14 
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1 distinguishes between entities that belong to different applications 30, so that entities can be 

2 identically named for completely different applications 30 with different security ratings, an 

3 owner Field that determines which user 18 may modify an entity's security settings, and a type 

4 Field that contains a reference to what type of object the entity is, be it an Application, Screen, 

5 Image, Grid, Field, etc. 
6 

7 The data base 120 also contains a Groups Table 126 that holds all available groups which 

8 may have security settings provided by entities, and contains a handle Field that references the 

9 group 126 for lookup by other tables in the database 120, a group name Field that holds the 

10 actual group name, a group owner Field that determines which user 18 may add or remove other 

1 1 users 18 from the group, or even delete the group, and a group application Field that determines 
4,2 which application 30 this group is for. The database 120 also has a Members Table 128, which 



sets the memberships for each group, based on the entries from users 134, groups 126 and 



*'W application tables 1 14. The members table 128 contains a handle Field that references the 



member for lookup by other tables in the database 120, a mem group id Field that indicates what 



group the member belongs to, through groups table 126, a mem application id Field that 

*17 indicates what application 30 this specific member entry is for, through the application table 114, 

1*8 and a mem user id Field that holds what the member's user id is through users table 134. 

149 

M 

jj2p The database 120 also can have a Perm Ivars Table 130 that holds any customized user 

H\ settings for the application 30 by references to a user ID Field that holds a reference to the user 

22 table's handle field to reference the proper user 18, a name Field that holds the name of the 

23 Permanent Ivar, and a value Field that holds the value the Ivar is to take on when the application 

24 30 loads. The data base 120 also has a Permissions Table 132 that holds what permissions each 

25 entity has based on the application 30 and the group id by referencing a handle Field that 

26 references the group permission number for lookup by other tables in the database 120, an entity 

27 name Field that holds the entity name that these permissions are for, a per application id Field 

28 that holds which application 30 the entity belongs to, via the application table 1 14, a per group id 

29 Field that holds which group these permissions are for via the groups table 126, a permission add 

30 Field that holds whether or not the group has permission to add to the entity, True or False, a 

15 




1 permission del Field that holds whether or not the group has permission to delete from the entity, 

2 True or False, a permission write Field that holds whether or not the group has permission to 

3 write to the entity, True or False, and a permission read Field that holds whether or not the group 

4 has permission to read from the entity, True or False. The database 120 can also have a Users 

5 Table 134, as described above with reference to table 118. 
6 

7 Accordingly, once the request 110 have caused the system 10, according to the 

8 application 30, to process the request 110 according to the databases 1 12, 120, the request 1 10 is 

9 either allowed with appropriate permissions 136, or is denied. If the request 1 10 is allowed, then 

10 the security settings come back from the respective server 28 according to the application 30 and 

1 1 the login message is sent to all corresponding entities of the application 30. Once a 
,12 entity receives the login message, it checks it's security on creation and whenever 

y 

^ilB the user 18 logs in. If an entity passes security, its visibility is set to true for the interface of the 
CO 

4j4 device 18, or otherwise false (invisible). The application security can be based on a particular 

s *l*5 entity, the group to which the current user 18 belongs to and the application 30. The final 

11116 security for an entity is a union of all securities that fit the entity/group/application combination, 

5 ,17 as determined by the particular application 30 operating on the system 10 for a selected 

!:i!8 combination of components contained in the tiers 14, 16, 26 concerned. 

I;f1 
k*9 

!^0 Middle Tier Technology 

■21 The middle tier 26 technology of the system 10 can be provided in the central platform 

22 application 30 by use of the middle tier parameters 52. For example purposes, such as but not 

23 limited to, three middle tier 26 architectures can be supported by the central platform application 

24 30 are Pass Through 24, EJB 28a, and Component Object Model 28b. Set up and 

25 implementation of the middle tier 26 components in the central platform application 30 can 

26 facilitate hiding details of running multiple transactions from users, as well as managing and 

27 pooling resources, to optimize system resources as well as scalability, reliability, and security. 
28 

29 The Component Object Model Architecture 28b and associated operating platform 29b 

30 helps devices 18 to make remote procedure calls and invoke services provided by COM- 

16 
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1 compliant components, whereby the COM standard of component interoperability and re- 

2 usability enables software developers to build highly distributed systems by assembling reusable 

3 components from different software vendors. The COM standard also provides mechanisms for 

4 management of shared memory between components, whereby the devices 18 can request a 

5 COM object of a specified type. The COM implementations can pool COM objects and return 

6 these pooled objects to requesting devices, whereby when a device is finished using a particular 

7 requested object the instance it is returned to the pool. Accordingly, the parameters 52 

8 concerning business logic and database queries can be expressed in the abstract notation of the 

9 file 30, such as XML format, to be used to generate COM objects that reside on the COM server 

10 28b. These COM objects can interact with other customized, client specific COM objects as 

1 1 required to meet client needs. 
12 

a 

$3 The parameters 52 can also be used to specify operational behavior of EJB server 28a and 

.3,4 associated platform file 29a. EJBs are components written in the JAVA programming language, 

"lo which can be run on any platform and operating system that supports the EJB standard, thereby 

facilitating the program designer to focus on the business logic of the application 30 and 

4V minimizing regard to server specific complications. Referring to Figure 4, the client devices 18 

Ml8 communicate with the back-end of the architecture of the sever 28a by using sockets and XML 

i:n 

\W as the communication medium 138, which is directed to an intermediate level Java application 

]djo 140. This application 140 interprets XML sent to it from the client level applications 18 into 



l^l RMI calls 142 and forwards these on to the EJB server 28a. Referring to Figure 5, the EJB 

22 Server 28a comprises entity beans 144a,b and session beans 146. It should be noted that the 

23 entity beans 144b has persistence managed by the bean, and the entity beans 144a in which 

24 persistence is managed by the container. The bean 144b itself is responsible for making JDBC 

25 calls to the database 20a,b to implement necessary database functionality though the 

26 corresponding interface 21a,b. The entity bean 144a makes less complex calls to the container 

27 and the container takes care of low level details of database 20a,b access. Accordingly, EJB 

28 servers 28a can be programmed to handle underlying transaction management details. The 

29 system 12 can be programmed by the parameters 52 to generate EJBs 28a from the abstract 



17 



1 notation description of the application 30, thereby providing such middle tier 26 services as 

2 transactions, security, database connectivity, threading, and persistence. 
3 

4 Further parameters 52 can be used to implement platform independent techniques for call 

5 procedures to objects across diversely distributed systems, as well as the ability to pass through 

6 corporate firewalls in order to transmit data obtained or returned to the data sources 20a, b. 

7 Accordingly, parameters 52 defining the Simply Object Access Protocol (SOAP) can be used to 

8 specify functions under the "request/response" message model. The parameters 52 can include 

9 information on Remote Procedure Calls (RPC), which can be serialized into SOAP messages 

10 defining the call parameters. A further parameter 52 can include information on the 

1 1 interpretation of SOAP messages by a server capable of remitting objects, as well as calls on a 

12 "session Object" to execute the actual procedure code to return the desired value. This value can 
«jlj3 be serialized into the SOAP message and then sent back to the client side, where it is then 

deserialized. Accordingly, the parameters 52 are used in the application 30 to help define the 

^$5 call procedures as well as the pass parameters used with the call procedures. Furthermore, 

|J6 SOAP messages containing error values (if the desired procedure is not successfully 

m 

17 implemented) can also be included, so that the platforms 29a, 29b can be used to define 

structures to return requested values, as well as error values. These parameters help the systems 

cn 

1,1,9 of the middle tier 26 to become distributed and to facilitate the full accessibility of shared 

tfo objects. Further parameters 52 can include instructions for transporting XML documents 

H*l through HTTP, thereby providing for SOAP messages that are understood by application 

22 supporting the technologies of both HTTP and XML. 
23 

24 Implementation of the business logic on the middle tier 26 can be facilitated by the use of 

25 neurons and reports, as the system 12 is built upon a fully message-based architecture. 

26 Preferably the neurons can be implemented in the first tier 14. Visual elements on the client 18 

27 such as buttons generate and respond to messages over the network 22 when users interact with 

28 them. Some examples of these messages for database 20a,b interaction can include: a window 

29 closing when a user clicks the "close" button, a row being selected when a user clicks on a row 

30 of a grid, and an input box changing when a user enters a value and clicks the "change" button. 

18 



1 This messaging system incorporated in the application 30 yields an event-driven architecture, 

2 which facilitates the development of behaviors in the applications 30. These messages are sent 

3 on distinct channels to the central server 28a,b location, which coordinates the distribution of 

4 messages. The central system 28a,b distributes the messages to every listener device 18 that is 

5 listening to the channel over the network 22 on which the message is being sent. Relaying all of 

6 an application's 30 messages to the central system 28a,b facilitates the customization and 

7 interaction with the application's 30 behavior. 
8 

9 Certain applications 30 use "Neurons" for complicated behaviors, which are preferably 

10 implemented in the first tier 14 business logic. Neurons are an abstract concept that can be 

1 1 defined as something that receives, interprets, and sends messages for the system 10 over the 

12 network 22. In the case of implementation of neurons on the first tier 14, the neurons send 

4& messages within the platform 19a, b, c, d of the devices 18a, b, c, d. Neurons are programmatic 

hl|4 in Extensible Markup Language (XML) but can be coded in Java for intricate and or user- 

l*lp specific behaviors, for insertion into the file 38 and/or generator 42 to produce the central 

Sjy6 application platform 30. Neurons permit the specification of arbitrary behaviors. 

m 

; ; i,7 Example XML 

life 

1*9 01 <entity ID="set_date_neuron" type="Neuron"> 



l $) 02 <param name="in"> 

03 <channel>WidgetStatus.comm</channel> 

Hi 04 </param> 

23 05 <param name="middle"> 

24 06 <waitfor> 

25 07 <condition paramname-'action" >"loaded"</condition> 

26 08 <condition paramname-'type" >"WidgetStatus"</condition> 

27 09 <condition paramname="id" >"title_screen"</condition> 

28 10 <create var="date" /> 

29 1 1 <getglobal var="date" ivar=".date" /> 

30 12 <setglobal 

31 vai-".main.title_screen.grid.label.current_date"> Sdate 

32 13 </setglobal> 

33 14 <java> 

34 15 //insert java code into generated code here 

35 16 </java> 
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1 17 </waitfor> 

2 18 </param> 

3 19 </entity> 
4 

5 The example XML above represents the neuron that acts to set a date within an 

6 application when executed. Neurons listen to specific channels over the network 22, or within 

7 platform 19 depending on the tier 14, 26 used, for the instruction to execute their body code. 

8 The Line 03 illustrates that this neuron is listening to the channel "WidgetStatus.comm." Any 

9 message sent across this channel will trigger this neuron to execute its body code. The body 

10 code of a neuron is encapsulated within "<waitfor>" tags (Lines 06 through 18). Before 

1 1 executing this body code, the neuron will check to ensure that certain conditions have been met. 
\Tjjl These conditions can be found on Lines 07 through 09. The first condition (Line 07) relates to 

. : !! a 
a i a 

jI3 the action that must have occurred to trigger this neuron. This condition will check to ensure that 

Ik the neuron was triggered by an "action" of type "loaded". Recalling that users on the client side 

al<5 trigger neurons, some other examples of "action" conditions include: a grid being "opened", a 

m 

|l|6 button being "clicked", or in this case, a screen being "loaded". 
0 

$18 The second condition (Line 08) relates to the type of message that triggers this neuron 

jj lp across the "WidgetStatus.comm." channel. Line 08 specifies that the message must be of type 

12)0 "WidgetStatus". The third condition (Line 09) relates to the origin of the message that triggers 

21 this neuron. This condition will check to ensure that the neuron was triggered by a "title_screen" 

22 widget. When all of the above conditions have been met, this neuron will create a variable called 

23 "date" (Line 10) and assign it the value stored in the Intelligent Variable (IVar) ".date". IVar's 

24 are generally variables that hold data within widgets of an application. IVars such as ".date" and 

25 ".time" are unique IVars because they are derived from the system and not from widgets of an 

26 application. When executed, Line 1 1 will retrieve the current date from the system and assign 

27 this value to previously declared variable known as "date". Line 12 makes use of an anchor to 

28 set a label widget within a screen of an application to display the current date. To accomplish 

29 this, the "date" variable that now stores the current date must replace an existing variable within 

30 the label widget. The existing variable within the label widget is accessed by the use of an 
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1 anchor, which essentially acts as a hierarchal reference. This anchor in this particular example is 

2 ".main.title_screen.grid.label.current_date". Accordingly, highly specialized behaviors can be 

3 implemented for highly customized software solutions 30 by inserting native Java code into the 

4 body of the neuron. Lines 14 through 16 demonstrate how we insert native Java Code into 

5 generated code. Choosing to do so, however, can remove platform independence. 
6 

7 A further construct to implement the business logic of the middle tier 26 are Reports, of 

8 which the functionality of Neurons is quite similar. The Reports of the application 30 facilitate 

9 presentable documentation with regards to data-centric software applications 30. Reports contain 

10 application server business logic. Reports are useful for data processing and global calculations. 

11 A report could be used to create, such as but not limited to, a balance sheet, income statement, or 

12 post transactions to a series of accounts. Reports are specified using a similar Document Type 

O 

stfj Definition (DTD) to that used by Neurons. 




Example XML 



(IF 
(18 
1339 
SO 
124 
122 
!28 
124 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 



01 <entity ID="Example_Report" type="Report"> 

02 <param name="name">this is a report</param> 

03 <param name="code"> 

04 <report> 

05 <reportmain> 

06 <body> 

07 <center>this is an example report</center> 

08 <create var="pl"/> 

09 <set var="pl">-K/set> 

10 pi = <get var="pl" /> 

11 <include file="layout.xmr7> 
12 



13 <pp> 

14 <image source="../image/ariussoftware.gif"/> 

15 <item>Insert Data K/item> 

16 <item left="10" top="10"> 

17 Insert Data 2 

18 </item> 

19 <item left=" 10" top="30" width="10"> 

20 Insert Data 3 

21 </item> 

22 <item left="200" top="40" height="300"> 

23 <image source="../image/custom_picture.gif"/> 

24 </item> 

25 </pp> 
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1 26 

2 27 </body> 

3 28 </reportmain> 

4 29 </report> 

5 30 </param> 

6 31 </entity> 
7 
8 

9 The example XML above represents Report entities are defined in the XML descriptions 

10 38. Multiple reports that use similar layout and presentation properties can reference an external 

1 1 XML file to handle these similarities. This feature is displayed in Line 1 1 . Line 07 illustrates 

12 one of the layout and presentation tags that are used in reports. The <center> tag is used to 

13 center align data. Lines 08 through 10 highlight our ability to use Intelligent Variables (IVars) in 

14 our reports. IVars can be used by queries to retrieve data from the database 20a,b for the purpose 
.1,5 of generating reports. Lines 14 and 23 highlight how images can be inserted into our reports to 
*fi> enhance the visual appeal. Line 13 contains the tag "<pp>", which stands for Precise 

5 ji i 

4j7 positioning. Business data can be inserted in Lines 17, 19, and 22. The <item> tags 

*1^8 encapsulating these lines are used to define layout properties for precise positioning. 



]io Accordingly, as discussed above, Reports are written within file 38 under Report entity, 

!||l under the param named"code". Neurons are also written in the file 38 under the Neuron entity, 

122 but it does not have a param named"code". Neurons and Reports share a lot of functionality 

]2j3 between them. Reports are used to create visual pages, where Neurons are used to help with 

!24 functionality. 
25 

26 Example components of reports can include: 

27 <entity ID="Reportld" type="Report"> 

28 <param name="name"> Report Eg</param> 

29 <param name="width">800</param> 

30 <param name="code"> 

31 <report> 

32 <reportmain> 

33 <header> 

34 <font size="4">Report Eg</font> 

35 <break/> 

36 </header> 

37 <body> 

38 <table border="0"> 

39 <row> 
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1 <cell>Celll</cell> 

2 <cell>Cell2</cell> 

3 </row> 

4 </table> 

5 </body> 

6 </reportmain> 

7 </report> 

8 </param> 

9 </entity> 
10 

1 1 Explanations of the above components are: 

12 Report 

13 A tag for when dealing with a report entity under param named "code". 
14 

1 5 Reportmain 

16 Indicates the location of the main processing loop. 

n 

m Include 

'S]9 This tag is used to read in data from a file. If the file exists, and its contents can be read, the 

jgp contents of the file are outputted in place of the tag. The file attribute specifies the file to be 

'21 included. The file must have the correct report syntax. E.g. <include file-'Name of File7> 

m 

m 

Header 

This tag is used at the beginning of a report. The header text between the opening and closing 

|'25 tags is used to display the report title. Fonts and layout tags may be used as well in between the 

26 header tags. 
27 

28 Body 

29 This tag is usually inserted after the header tag. The text between the opening and closing body 

30 tags will be the majority of the report. Almost everything you want displayed can go here. 
31 

32 Footer 

33 This tag is much like the header or body, except this tag is used at the bottom of the report and 

34 will follow the closing body tag. Text between the opening and closing tags will be displayed at 

35 the bottom of the report. Font and layout tags may be used as well in between the footer tags. 
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1 E.g. <header> 

2 ...Display Header Info... 

3 </header> 

4 <body> 

5 ... 

6 ...Body of Report... 

7 ... 

8 </body> 

9 <footer> 

10 ...Display Footer Info... 

1 1 </footer> 
12 

13 Left, Center, Right 

14 These tags are used to align whatever is in between the opening and closing tags. Alignment is 

1 5 relative to the page. 

16 

Q 

«I37 Bold, Italic, Underline 

These tags will format whatever text is in between their opening and closing tags. 

M 

i2fi Table 
HI 

21 This tag will define a table, much like that of an HTML table. The border attribute is assigned an 

jjjfe interger that will define the thickness of the border. The width attribute is assigned an integer 

\23 that will define the width of the table, as similarily the height attribute describes the height of the 
table. 

125 

26 Row 

27 This tag belongs between the table tags. The row tag defines a single row in the table. For every 

28 set of opening and closing row tags, one row exists in the table. The tag has a height attribute 

29 that is assigned an integer. 
30 

31 Cell 

32 This tag belongs between the row tags. The cell tag defines one cell in the table. If there were 

33 twenty opening and closing cell tags between any row tags, then the table would have twenty 

34 columns. This tag has a width attribute that is assigned an integer. 
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1 

2 Font 

3 The font tag is used on text. Whatever text is between the opening and closing font tags will be 

4 affected. The font attributes are name - font name, size - size of font, and color - color of font. 
5 

6 Image 

7 This tag allows the insertion of images into Reports. It has a source attribute, which is assigned a 

8 string containing the location of the image. Width and height attributes both take on integers 

9 describing the width and height of the image. 
10 

1 1 Margin 

J2 This tag allows us to set margins for the Header, Body, and Footer. The tag must be contained in 

43 the desired section or sections. Margin tags have attributes left, right,top,and bottom, which set 

it j4 distance from the sides of the page. 

\3£ Break 
IIP 

r 17 This tag will simply move to a new line in the Report. 

m 

j*9 PP 

j2j0 This 'precise positioning' tag will define an area where items will be inserted. Width and height 

s21 attributes describe the width and height of the area. 
22 

23 Item 

24 These tags are used between the opening and closing pp tags. Item tags are used to surround text, 

25 images, etc. Attributes xloc and yloc describe the location of an item relative to the top left 

26 corner of the pp tag. Width and height are used as well to describe the width and height for the 

27 item. At runtime, if width or height of an item has gone over the pp tag's boundaries, the pp tag 

28 will expand to fit all the items. 
29 

30 There can be tags that are common to both Neurons and Reports, such as: 
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1 Funcdef 

2 This tag requires attribute name which is the name of the function. Optional attributes type, used 

3 when the function has a return type, and var, the name of the variable that is returned in the 

4 function, are also available to use. 

5 E.g. <funcdef name="hello"> 

6 <paramdef name="p 1 " /> 

7 <paramdef name="p2" /> 

8 <code> 

9 <if>'$pl'eqT</if> 

10 .... 

1 1 <elseif>'$p2' eq *- 1 '</elseif> 

12 .... 

13 <else/> 

14 <if>true</if> 

15 .... 

fl;6 <endif/> 

.... 

W& <endif/> 

|^ </code> 

% </funcdef> 

§ 

Sfe Paramdef 

|2;p Paramdef is used to define arguments for defined methods. Name, the name of the parameter, is 

ni 

|2j4 the required attnbute of this tag. An optional tag, type, is also used to define the parameter type, 

feb See the above example. 



27 Funcuse 

28 This tag is used to call a defined function. The name attribute is specified with the name of the 

29 defined function. An optional attribute, var, can equal the name of a variable that will take on the 

30 result of the function. E.g. Assume a function add is defined: 

31 <create result/> 

32 <funcuse name- ! add ,f var="result"> 

33 <paramuse name="pl ">25</param> 

34 <paramuse name="p2">10</param> 

35 </funcuse> 

36 The value in variable result will be 35. 
37 
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1 Par amuse 

2 This tag is used in conjucntion with the Funcuse tag to pass in arguments for a function. The 

3 attribute name specifies the paramter of the function. Take a look at the above example. 
4 

5 Java 

6 Java code in between these two tags gets dropped directly into the generated code. 
7 

8 For 

9 This tag is used to create a loop. It requires attributes var, start, end, inc, and compare to be set 

10 within the opening tag. Var can be set equal to the name of a variable, otherwise a variable with 

1 1 that name will be created. Var will be set to the value of start, so that each time through the loop, 

12 all statements between the opening and closing tags will execute, and var will be incremented by 

<© inc. This will continue until the value of var, compare, and end evaluates to false, where compare 

pfj 

is an operator (see Conditional/Control Tags). 

[ft E.g. <for var="Var" start= ,, Number" end= M Num" inc="Num" compare- f Oper M > 

jlJS ...(Statements)... 

1*7 </for> 

j 

% Squery 

\20 This tag is used to load an squery. The qname attribute defines the query name that is to be 

j2|l loaded. 

•22 E.g. <squery qname- 'Name7> 
23 

24 Numcols 

25 This tag is used to return the number of columns in an squery. Query name attribute qname, 

26 name of the query, and variable attribute var, name of the variable used to store the number of 

27 columns, must be specified within the tag. 

28 E.g. <numcols qname- 'Name" var="Variable"/> 
29 

30 Numrows 
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1 This tag is used to return the number of rows in an squery. Query name attribute qname, name of 

2 the query, and variable attribute var, name of the variable used to store the number of rows, is be 

3 specified within the tag. 

4 E.g. <numrows qname- 'Name" var="Variable7> 
5 

6 Setrow 

7 This tag is used to set the current row index in an squery. Query name attribute qname, and row 

8 attribute row is specified within the tag. 

9 E.g. <setrow qname- 'Name" row= f, Number'7> 
10 

1 1 Getrow 

12 This tag is used to return a row from an squery. Query name attribute qname, and variable 
=£8 attribute var, which holds the returned value, is specified within the tag. 

:|4 E.g. <getrow qname="Name" var="Variable7> 

?Ij5 Setcell 

17 This tag is used to set the value of the indexed cell. Query name attribute qname specifies the 

^$8 query name, rowindex attribute specifies the row number, colindex specifies the column number, 

|,fi 

1-1.9 and value attribute value is the value to which you want to set the cell. 

3:1 

g0 E.g. <setcell qname="Name" rowindex="Number" colindex= M Number" value="Val7> 
1*1 

22 Getcell 

23 This tag is used to get the value of an indexed cell. Query name attribute qname specifies the 

24 query name, rowindex attribute is used to specify the row number, colindex specifies the column 

25 number, and variable attribute var is the variable that the result will be put into. 

26 E.g. <getcell qname-'Name" rowindex- 'Number" colindex- ! Number" var="Var7> 
27 

28 Deleterow 

29 This tag is used to delete a row from an squery result set. Query name attribute qname, and row 

30 attribute row is specified. 



28 




1 E.g. <deleterow qname= M Name" row=' , Number'7> 
2 

3 Addrow 

4 This tag is used to add a blank row to an squery. Query name qname is specified within the tag. 

5 E.g. <addrow qname- 'Name7> 
6 

7 Sqsave 

8 This tag is used to save an squery result set back to the database. Query name attribute qname is 

9 specified within the tag. 

10 E.g. <sqsave qname="Name"/> 
11 

.12 Create 

U 

*IS This tag is used to create a variable. Within this tag, attribute var is followed by the variable 

44 name. 

]¥5 E.g. <create var="VariableName7> 
US 

~P Set 

jjjj3 This tag is used to set the value of a variable. Within this tag, attribute var is followed by the 

l'li-9 variable name. After closing the tag, follow it by the value for the variable. Note that a variable 

M 

j2p must be created before it can be set. 

te'l E.g. <set var="Age">23</set> 

22 The above will set variable age to 23. 
23 

24 Get 

25 This tag is used to get the value of a variable. Within this tag there is the attribute var followed 

26 by the variable name. 

27 E.g. <create var="temp"/> 

28 <set var="temp">Hello World!</set> 

29 temp=<get var="temp7> 

30 The above should print out: temp=Hello World! 

31 
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1 Initglobal 

2 This tag is used to initialize a global variable. Within this tag there is the attribute var followed 

3 by the variable name. 

4 E.g. <initglobal var="GlobalVarName"/> 
5 

6 Setglobal 

7 This tag is used to set the value of a global variable. Within this tag there is the attribute var 

8 followed by the variable name. Then close the tag and follow it by the value for the global 

9 variable. Note that a global variable is initialized before it can be set. 
10 E.g. <setglobal var="GlobalVarName n >Value</setglobal> 

11 

12 Getglobal 



<getglobal var="TempLocalVar" ivar="GlobalVarName'7> 



© This tag is used to get the value of a global variable and set a local variable to the result. Note to 

m 

4<4 reference global varibles you load them into a local variable. Within this tag there is the attribute 

jijb var followed by the local variable name and there is the attribute ivar followed by the global 

i t:a 

IBS variable name, 
ffl 

} 7 E.g. <create var="TempLocalVar7> 

it 5 
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|2j0 Example components of Neurons for first tier 14 or middle tier 26 can be: 

|]2 1 <entity ID="sample__test_neuron n type="Neuron f, > 

22 <param name- 'in"> 

23 <channel>channelA</channel> 

24 </param> 

25 <param name- 'middle"> 

26 <waitfor> 

27 <condition paramname="mesgName ,, >"Example l, </condition> 

28 <message mesgname-'Name" type- 'Widget" channel- 'chaimelName M ></message> 

29 <setmessageparam mesgname-'Name" param- 'colour">''blue"</setmessageparam> 

30 <send message="Name7> 

31 </waitfor> 

32 </param> 

33 </entity> 
34 

35 Explanations of the above components are: 
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1 sum 

2 This tag will enable you to find the sum of a specified column in an squery. The attribute query 

3 is the name of the squery, the attribute table is the table name of the the column you would like 

4 to use, and of course the field is the name of the column to use. 

5 E.g. <sum query="queryName" table- f tableName n field-' fieldName ! 7> 
6 

7 avg 

8 This tag will enable you to find the avgerage of a specified column in an squery. The attribute 

9 query is the name of the squery, the attribute table is the table name of the column you would 

10 like to use, and of course the field is the name of the column to use. 

1 1 E.g. <avg query="queryName" table- 'tableName" field="fieldName7> 

Q 

*IB createmessage 

iljfl These tags reside under the param named "middle" in a neuron entity. This tag will create a 
message that the neuron can later send on the specified channel. The attribute type is used to 

IBS specify the type of message. The possible values for type are described under the Messaging 

m 

J 7 System section. The msgname attribute is an textual name you may assign the message. The final 

5 i;8 two attributes specify which channel to send the message, but they differ slightly in functionality 

lift 

\W and only one of the two attributes must be specified. The channel attribute specifies what channel 

u 

AO you want to send the message on, and when the message is sent it is sent to everone listening on 

»21 that channel. The relative channel attribute differs slightly in that it will still send the massage on 

22 the specified channel, but only from a certain height in the tree. So, if we had two instances of a 

23 screen, this allows us to send messages only to other widgets on the same instance of a 

24 screen and not to both. 

25 E.g. <entity ID="neuron_id" type="Neuron M > 

26 ... 

27 <param name- 'middle'^ 

28 <createmessage type-'messageType" msgname-'messageA" channel="channelX M /> 

29 <createmessage type-'messageType" msgname- 'messages" relativechannel="parent.channelX" 

30 </param> 

31 ... 

32 </entity> 
33 
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1 channel 

2 These tags reside under the param named "in" in a neuron entity. The purpose of the channel tags 

3 is to specify which channels the neuron is to listen on. The name of the channel goes between the 

4 opening and closing channel tags. 

5 E.g. <entity ID="neuron_id" type="Neuron"> 

6 <param name="in ,! > 

7 <channel>channelA</channel> 

8 <channel>channelB</channel> 

9 </param> 

10 ... 

1 1 </entity> 
12 

13 setmessageparam 

14 These tags reside under the param named "middle" in a neuron entity. This tag allows you to add 
ft any user defined parameters ,o a message. The mesg-name attribute specifies the message that 

f!6 we are adding a parameter to. The param attribute specifies the name of the created parameter. 

SJ 

kfp The value of the parameter is enclosed between the opening and closing tags and between double 
quotes. 

IgO send 

:2 t l These tags reside under the param named "middle" in a neuron entity. It sends a specified 

lafe message using the message attribute to specify a message name. 
Q 

j23 E.g. <entity ID="neuron_id" type="Neuron"> 

24 ... 

25 <param name- 'middle 1 ^ 

26 <createmessage type="messageType" msgname-'messageA" channel- 'channelX" /> 

27 <setmessageparam mesgname-'messageA" param=' ! colour">' f blue"</setmessageparam> 

28 <send message=' t messageA ,t /> 

29 </param> 

30 ... 

31 </entity> 
32 

33 getmessage 

34 These tags reside under the param named "middle" in a neuron entity. The getmessage tag takes 

35 the message that fired the neuron and creates a specified variable that it is put into. The 
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1 mesgname attribute is the name of the variable to be created and for the message to be inserted 

2 into. The creation of this variable will then allow the user to read message information. 
3 

4 getmessageparam 

5 These tags reside under the param named "middle" in a neuron entity. The getmessageparam tag 

6 will read a specified parameter from a specified message and create a given variable and insert 

7 the parameter value into the created variable. The var attribute is the name of the varibale to be 

8 created and store the result. The mesgname attribute is the name of the message to be used. And 

9 the param attribute is the paramter name that we are interested in. 

10 E.g. <entity ID="neuron_id" type="Neuron"> 

11 ... 

12 <param name- 'middle"> 

13 <getmessage mesgname- 'messageVar7> 

'lA <getmessageparam var="paramValue f ' mesgname- 'messageVar 1 ' param="colour'7> 

$£> </param> 

;*!> ... 

ik </entity> 

» 

!& condition 

m 

s20 These tags reside in two places. They may reside between the waitfor tags or they may be 

between the seekmessage tags. These tags simpply specify a condition on message parameters. 
The paramname attribute defines the name of the parameter that we want to test. Between the 

w 

\23 opening and closing tags, surrounded by double quotations, will be the desired value of the 

24 parameter. The attribute op may also be included an operator to help with a range. There 

25 is one extra operator for the condition tags which is ambig. This is used to compare widget 

26 names to general cases. So any instance of that widget will evaluate to true. 

27 E.g. <condition paramname="colour f, >"blue"</condition> 

28 <condition paramname- ! age" op-"lte"> M 23"</condition> 

29 <condition paramname- VindowName" op="ambig tl >".main.a_screen.b_grid M </condition> 

30 <!-- so in this last condition .main#l.a_screen#3.b_grid#7 will evaluate to true, 

31 but something like .main#l.a_screen#5.c_screen#3 will evaluate to false — > 
32 

33 waitfor 

34 These tags reside under the param named "middle" in a neuron entity. The opening and closing 

35 tags form a block of code that will be executed when certain conditions are met. The opening tag 
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1 is followed by a set of conditions that have to be met before it can then proceed with the rest of 

2 the code contained within the waitfor tags. Every set of waitfor tags are executed sequentially. 

3 So if we are currently at the first waitfor tag and the conditions are met for the second waitfor 

4 tag, then only the code outside all of the waitfor tags will be executed. Otherwise if the message 

5 that fired the neuron meets the conditions of the first waitfor tags and the neuron has not yet 

6 executed the code between the first waitfor tags, then it will do so. Note that the condition tags 

7 are optional. If no condition tags are specified then when a message fires the neuron then the 

8 code within the waitfor tags will be executed since there is no conditions to test. 

9 E.g. <entity ID="neuron_id" type= M Neuron"> 

10 ... 

1 1 <param name- f middle"> 

12 <waitfor> 

1 3 <condition paramname- f colour">"blue M </condition> 

14 ...(Statements)... 

15 </waitfor> 

16 <waitfor> 

17 ...(Statements)... 
W& </waitfor> 

1?9 </param> 

% </entitiy> 

iiii. 

&3 pushmessage 
171 

*24 These tags reside under the param named "middle" in a neuron entity. Neurons each provide 

n 

I^j5 their own individual statck where messages may be stored for future uses. The attribute 

s26 mesgname is the name of the message that you want to push onto the statck. Note that you must 

y 

j2|7 first use the 'getmessage' tag before pushing a message. 



29 popmessage 

30 These tags reside under the param named "middle" in a neuron entity. This tag allows us to pop a 

3 1 message off the top of the stack into a specified variable. The attribute mesgname is the name of 

32 the variable that will be created as well as hold the message that was poped off the top of the 

33 stack.. 
34 

35 seekmessage 

36 These tags reside under the param named "middle" in a neuron entity. This tag will allow us to 

37 find a message in the stack based on a number of conditions. The attribute var is the name of 
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1 variable that the result will be assigned to. If a message is found based on the conditions then the 

2 index in the stack will be assigned to the specifed variable. If nothing is found then -1 is assigned 

3 to the variable. Note that only the first message that satisfies the conditions is returned. The 

4 conditions must be inside the opening and closing tags of seekmessage. 
5 

6 peekmessage 

7 These tags reside under the param named "middle" in a neuron entity. This tag will allow us to 

8 retrieve a message out of the middle of the stack. Given an index in the stack we may retrieve the 

9 message into a new variable that we also specify. The attribute var is the index on the stack 

10 where the message we want resides. The attribute mesgname will be the newly created variable 

1 1 that will hold the retireved message. 

12 

O 

\l$ dropmessage 

These tags reside under the param named "middle" in a neuron entity. This tag will allow us to 
remove a message from the middle of the stack. Given an index in the stack we may remove that 

1X35 message. The attribute var is the index on the stack where the message we want to drop resides. 

1 7 E.g. <entity H)="neuron_id" type="Neuron"> 

S*£ - 

<param name="middle , '> 

!20 <getmessage mesgname= M messageVar , 7> <!-get the message that fired us-> 

i2!l <pushmessage mesgname="messageVar7> <!-push it onto the stack-> 

122 ... 

&3 <create var="index'7> 

24 <seekmessage var="index"> 

25 <conditionparamname= M colour n > ,f blue"</condition> 

26 </seekmessage> 

27 <! -index should contain the index on 

28 the stack if the message was found 

29 with a parameter colour=blue — > 

30 <peekmessage var="index" mesgname- f foundMessage7> 

3 1 <!-foundMessage should contain the 

32 actual message — > 

33 <dropmessage var^'index" /> 

34 <!~the message previously found is 

35 removed from the stack — > 

36 </param> 

37 ... 
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1 </entity> 
2 

3 Accordingly, the implementation of business logic including Neurons in the first tier 14 

4 and Reports in the middle tier 26 can be programmed by the software designer for inclusion with 

5 the parameters 40, 44. 
6 

7 Abstract Based Declarations 

8 Referring to Figure 2, the development system 12 also uses input parameters 40 to help 

9 generate the abstract application description file 38, from which the central platform application 

10 30 is generated. The descriptions 38 can be store in platform independent format. The file 38 is 

1 1 preferably written in an abstract notation such as XML, which makes use of structure tags to 

12 describe the data contained in the file 38. In particular, HTML can also be used as an abstract 
ttB language with standard tags, however the XML format also provides capability of defining tag 

names to further accurately describe the data contained in the file 38. Accordingly, the file 38 

1$ contains descriptions of applications written in the abstract notation language, XML, whereby 

S1'6 every element of the application 30 is represented by an entity that is described in the file 38. 

jl$ These entities in general can represent a visual, behavioral, and data aspects of the application 

%8 30. 

Q 

j2p The visual entities can include screens, buttons, and images. Behavioral entities can 

jiPl involve neurons. Data entries can include records, fields, and queries. As discussed below, the 

22 entities can be defined by the respective type, parameters, children, and are referenced by their 

23 ED. The entities in the application 30 can have parent child relationships, which determine the 

24 overall structure of the application 30. Accordingly, the file 38 once assembled is a declaration 

25 of all the various components which can be found in the application 30, such as but not limited to 

26 grids, records, screens, database queries, and database tables. These components are then related 

27 to one another by a series of parent/child relationships which facilitate the components to be re- 

28 used (i.e. having multiple parents). A sample code listed below is used to illustrate the 

29 relationships that can exist between entities and to exemplify the usage of the XML format to 

30 provide the files 38: 
31 
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1 <entity ID="batch_trans" type="Screen"> 



2 02 <param name= !l name M >Transactions</param> 

3 03 <child name="batch_trans_grid"> 

4 04 <param name="row">l</param> 

5 05 <param name="column">0</param> 

6 06 <param name="rowspan ,, >l</param> 

7 07 <param name="columnspan">l</param> 

8 08 <param name="anchor">NORTH</param> 

9 09 <param name= ,, fill">BOTH</param> 

10 10 <param name="ivars">batch_grid.rowid = parent. parent, 

11 squery = parent. parent. batch_grid</param> 

12 11 </child> 

13 12 <child name="transactions"> 

14 13 <param name="row">0</param> 

15 14 <parara name="column">0</parani> 

16 15 <param name="rowspan">l</param> 

17 16 <param name="columnspan">l</param> 
|I8 17 <param name= n anchor M >CENTER</parani> 
=£p 18 <param name= n fill n >BOTH</paraiTi> 

Up 19 </child> 

*2h 20 </entity> 

ih 

21 <entity ID="batch_trans_grid n type= n Grid"> 

^ 22 <param name= M name n >Transactions</parain> 

s 25 23 <child name="batch_trans_query"> 

§P 24 </child> 

§17 25 </entity> 

m 

129 26 <entity ID= ,, transactions" type= f, Image H > 

!Sb 27 <param name= t, name ,, >Transactions Title</parain> 

b4 28 <param name =tl image f, >image/transactionstitle.gif</param> 

32 29 </entity> 

33 

34 Accordingly, line 1 of the sample code begins with the definition of the entity within the 



35 application 30. The entities type is declared near the end of line 1, which provides a "screen" 

36 which describes the screen within the application 30 to be generated. Line 3 is the first 

37 occurrence of the parent child relationship that exists between the entities, which for this 

38 example "batch_trans_grid" is being defined as the child of "batchjrans", which is now 

39 regarded as a parent. Each child entity can have its own separate definition, which is not 

40 included in the definitions of their respective parents. Further examination of the above example 

41 code shows that line 3 references line 21 to define "batch_trans_grid". Accordingly, lines 4 
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1 through 9 are lines of code that are specific to the layout system of the application 30 and 

2 describe how the "batch_trans_grid" entity will be visually represented in the graphical user 

3 interface 58 (see Figure 6) displayed on the device 18 by the application 30. Line 10 describes 

4 an Intelligent Variable (IV AR), which links the behaviors of the entities concerned. 
5 

6 Applications 30 that are considerably high in complexity generally involve an elaborate 

7 data structure, representing the intricate parent child relationships between the entities. 

8 Accordingly, referring to Figure 6, which is the example interface 58 for the device 18, has been 

9 generated as a result of the above presented XML code of lines 1 to 29. The interface 58 shows 

10 a series of widgets 60a, b, c or display elements, which are elements of the application 30 

1 1 represented by the entities in the above sample XML code. The variety of widgets 60 can be 

12 categorized into three main groups, visual 60b, interactive 60c, and data access widgets 60a. The 

U 

£3 visual widgets 60b can include labels, images, screens, and tabs. Interactive widgets 60c can 
CO 

A£ include buttons, clickable images, and input boxes. Data access widgets 60a can include grids, 

jft records, and reports. Accordingly, it should be noted that the above XML code description of 

iS> the sample user interface 58 contains a series of platform independent widgets 60a,b,c that are 

J 7 represented by the entities contained in the file 38, through which the program generator 42 can 

!|8 use to generate the application 30 on a variety of platforms, which are dependent upon the type 

\&9 of parameters 50, 52, 54 that are specified by the program designer. 

tel Referring to Figure 7, in order to support legacy data sources 20a, b you can create 

22 custom tables 150 and custom reports, by providing custom declaration 148 in the file 38. 
23 

24 Custom reports trigger a transaction like behavior such as purging old data in the 

25 databases 20a, b. They are constructed involving procedural method which returns a string of 

26 XML to be displayed. 
27 

28 Custom tables 150 are specified on a row level as many legacy applications are row 

29 oriented. Each row object needs to support seven simple operations: 
30 
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1 The first six methods can perform their function as specified, the seventh function can be 

2 defined but can be left empty. If the function is left empty no logging is supported on the custom 

3 table 150. Logging is used to synchronize various clients 18 without reloading all of their data. 

4 Assuming one user 18 makes a change and the other 18 wishes to update they could simply 

5 query the log for the changes made. If logging is not supported then they can reload all of the 

6 data. 
7 

8 Custom reports and tables 150 can be defined in two languages C# or Java. If defined in 

9 Java they can be used by either the passthrough system 24 or the EJB server 26. If defined in C# 

10 then they can be used in the COM 28b system. 
11 

12 The loadData() gets all the non-standard data from the datasource 20a,b and returns it in 

U 

$B the Table-Data, which is more or less a wrapper for a Vector of StringVectors, each of which is a 

£0 

^4 row in the table. The StringVector is a wrapper class created to lower the amount of excessive 

jtjj casting when using a Vector of Strings. The loadMetaData() gets the field information and 

WS returns it in a TableDef, which contains a vector of FieldDefs. Each FieldDef contains 

!,: ' 

11 information about a field such as its name, default value, and names of any queries that generate 
%p its pull-down menus in the case of a field that contains integers, which refer to the handle fields 
1*9 of other tables. The save(), saves changes to the data source 20a,b. Changes 

j2|p are stored within CustomTableBase 154 in a Vector of TableChange objects. TableChange 

'211 extends Vector and contains RowChange objects, each of which describes a single 

22 change to the data. Revision numbers can be used to inhibit conflicting data from reaching the 

23 data sources 20a,b and to facilitate optimization and sort TableChanges. 
24 

25 Furthermore, there are three integer fields 156, 158, 160 in the CustomTableBase 154. 

26 The loadedStatus 156 stores the revision number the table 162 was at when loaded. The 

27 lastCheckedStatus 158 is used with the sync() method, whereby sync() asks the data source 20a,b 

28 for changes made to it since lastCheckedStatus 158 and sets lastCheckedStatus 158 to the current 

29 revision number of the table 162. The sync() helps in the PassThru Query System when more 

30 than one client 18 is able to access the data source 20a,b simultaneously. However, if there is 
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1 only one clientl8, then it is anticipated that the data source 20a,b is in sync with that client 18. 

2 Under EJB 28a, it is possible that multiple users 18 can use the table 162 simultaneously, but 

3 preferably only one instance of the table 162 will exist at one time and therefore the table 162 

4 would be in sync with the database 20a,b. The currentStatus 160 represents the status the 

5 CustomTable 154 contains. This value 160 can be incremented whenever the table 162 is 

6 updated by the user, but may make no assumptions about the state of the data source 20a,b. The 

7 tableUpdate vector stores the TableChange for the changes made at revision foo at location (foo - 

8 loadedStatus - 1). 
9 

10 It should be noted that save() and sync() facilitate consistent pointer usage within the 

1 1 Custom Queries 148 of the application 30. It should also be noted that for tables 162 associated 
^2 with SQL Databases 20a,b exclusively, appropriate table access routines may already be 

=Jp included in the DBTable EJB 28a family and accordingly custom queries 148 may not be 
needed. 

!ft. 
I.* 

IJtjS Application Editor 

17 Referring to Figures 8a, b, c, d, e, f the application editor interface 62 can be executed on 

*;P8 an appropnate computer by the program designer to edit all desired features to be contained in 

i;n 

\W the file 38. The editor 62 facilitates the modification of application entities 66 and their 

hi 

,j-2j0 relationships 70, as well as to preview how the applications interface would look as accessed by 

I^l the devices 1 8. Accordingly, the application editor 62 allows for the entry of declarations for the 

22 application file 38. The editor 62 contains a graph button 64, which allows the program designer 

23 to see the relationships 70 between all of the graphically presented entities 66 in a graphical 

24 mariner in window 68. The presented graph in window 68 is a series of the entities 66 which are 

25 connected by directed lines 70. The application editor 62 also contains an entities button 72 

26 which opens a window 74 containing grids that allow modification of the entities 66 in the 

27 program 38. The window 74 allows the program designer to modify the properties of the entity 

28 66, add new entities 66, change entity types, and modify the relationships 70 and organization 

29 parameters for child nodes. The relations button 76 of the editor 62 can open an additional 

30 window 78 containing parent handle drop down lists 80, a child handle drop down list 82, a 
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1 scroll bar 83 to go through the various entities 84 as shown in window 74, and an additional 

2 button 86 to create new relationships 70, as well as a delete button 88 to delete relationship 70 

3 and a grid 90 to display parameter values of selected parent entities 66. The application editor 62 

4 also contains a preview button 92 to allow the program designer to review the various entities 66 

5 already incorporated into the application file 38, thereby providing a sample preview interface 

6 resulting from the entities entered thus far in the file 38 which will eventually be generated by 

7 the compiled version of file 38, i.e. central platform application 30, for display on the devices 18, 

8 such as the interface 58 shown in Figure 3. Figure 8f shows a sample interface 18 of the editor 

9 46 from Figures 8a, b, c, d, e. 
10 

1 1 The entity section 74 contains all the entities 66 entered thus far in the application file 38, 

^ whereby new entities 66 can be added by entering the new entities ID, changing of an entity type 

£8 by entering the new type, and changing an existing entity 66 ID, as well as browsing all the 

£8 

•ifi entities 66 contained in the file 38 thus far. The section 74 contains the parameters for the entity 

.„ t :; j 

jji5 66 currently selected, whereby the parameter values can be modified by clicking on the 

iW parameter value and changing as necessary. The section 74 contains a list of all the children for 

O! 

g j7 the parent entity 66 currently selected. Accordingly, the section 74 can be used to add a child 

jjtjS node 66 by clicking in the child handle column and selecting the entity you would like to include 

W9 as the child node. The section 74 contains all of the valid parameter names and their values for 

|2j0 the child node 66 currently selected, whereby these parameter values and names can be changed 

Ifl by clicking on the Parma value field and modifying the value contained therein as required. 
22 

23 Referring to Figure 9, when a widget 60 is added to the screen 58 the location must be 

24 specified, such as by using a number of cells 164. For example, the upper left cell 164 of the 

25 interface 58 can be referenced by (0,0). Accordingly, when adding a child entity to the screen 58 

26 to be represented by the corresponding widget 60, its displayed location can be defined by 

27 indicating row and column numbers. Furthermore, other layout options are also available, such 

28 as columnspan, rowspan, fill, and anchor. Columnspan and rowspan attributes specify the 

29 number of columns or rows the widget 60 will span in a particular cell 164 or group of cells 164. 

30 The fill attribute specifies how the widget 60 itself should fill its corresponding cell 164. Possible 
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1 values for the fill attribute are NONE, HORIZONTAL, VERTICAL, or BOTH. The anchor 

2 attribute may take on nine different values specifying a location inside the cell 164, such as 

3 NORTHWEST, NORTH, NORTHEAST, WEST, CENTER, EAST, SOUTHWEST, SOUTH, 

4 and SOUTHEAST, as shown in Figure 9b. The following code represents the example widget 

5 60 placement shown in Figure 9a: 
6 

7 widgetl : row=0 column=0 anchor=NORTHWEST 

8 widget2 : row=0 column=l rowspan=2 fill=HORIZONTAL anchor=WEST 

9 widget3 : row=l column=0 fill=VERTICAL anchor=NORTHEAST 
10 widget4 : row=2 column=0 columnspan=2 fill=BOTH 

11 

12 As defined above, widget2 expanded horizontally to fill available space, so the anchor 

13 value could as well have been CENTER or EAST. Widget3 expanded vertically to fill available 
space, so the anchor value could as well have been EAST or SOUTHEAST. Furthermore, in the 

13> event that no cell location is specified for the widget 60, the widget 60 would be added to the 

(19 

^,6 bottom of the cell 164 spanning across the entire row. In addition, widgets 60 are added to the 

\6 

j!j7 bottom in the same order as originally created by the application 30. This can facilitate the 

W& addition of widgets 60 to the bottom of the screen 58. Furthermore, for non- viewable widgets, 

E 19 there is usually no point in specifying a location on the cell 164. Accordingly, widgets can be 

|^|) added to the screen 58 without having to specify a particular location. 

121 

w 

j£§2 The connections 70 between the entities 66 (see Figure 8) provides a set of "entities" 66 

'ife in the application 30 connected to each other by a set of relationships 70 in a rather hierarchical 

24 fashion, even though some entities 66 have more than one parent 66. On the interface 58, many 

25 of the entities 66 turn into visible objects the user of the device 18 can see, such as but not 

26 limited to Grid, Graph, Navigator, and Screen. Other entities 66 may never be visible as widgets 

27 60, such as but not limited to Publish, and Query. Accordingly, referring to Figure 10, a 

28 relationships table 166 of the application 30 can monitor which entities 66 appear inside of other 

29 entities 66 on an interface screen 168 of the device 18. For example, which Tabs 170 are in the 

30 Screen 168 or which Fields 172 are in a Table 174, as displayed by the representative widgets 

31 168, 170, 174. However, other kinds of relationships 70 may not get separate tables in the 

32 metadata database 20a,b. For example, a current selection in a Navigator 176 might change the 
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1 currently displayed row or record 178 in the Table 174, or move the selection in a Grid. It might 

2 also affect the Query object that controls Grid contents, like in an accounting application, so the 

3 Grid shows all transactions 178 attached to the currently selected account in the Navigator 176. 

4 Accordingly, the construct that entities 66 use to communicate with each other in the application 

5 30 can be an Ivar or ivar 1 80. 
6 

7 The "I" in Ivar 180 stands for Intelligent, as in Intelligent Variables. Ivars 180 are used 

8 to connect 70 various entities 66 and permit them to work together intelligently. For instance, the 

9 Navigator widget 176 could choose which row of the database appears in a Record widget 178, 

10 or how to link a where clause of a Squery up to the value in an Input Field. In addition, not 

1 1 specifying full pathnames when targeting an entity 66 for connection 70 to other respective 

12 entities 66 can be accomplished by matching ivars 1 80. For example, if a Navigator N in the Tab 

".SSI? 

4$ X of screen B, which is a child of screen A, is to control the grid G right beside it in Tab X, it 

ITjl may not be necessary to point the navigator at A.B.X.G for functionability. Instead, an input such 

1?1> as wid=parent.parent.G, would specify where the grid is in relation to the navigator. More 

H 

|lg> complex situations, for example, might have a screen called Transactions that contains a Grid G 

fn 

17 which lists the current set of transactions. The Transactions screen is a child of the Accounts 

screen, which has a grid AG. Selection of an account in AG and clicking the button would result 

!>>; 

iW in the Transactions screen popping up with a list of the various transactions that were done on 

M 

j2p that account. In using Ivars 180, this could be accomplished by referring the squery in the 

f24 Transactions.G grid to parent.parent. AG, which would find the appropriate AG. This is in 

22 comparison to specifying the full path A.B.Accounts.AG. Accordingly, the queries 

23 (functionality) need not be changed in response to a rearrangement of the layout (formatting). 

24 Furthermore, the ivars 1 80 facilitate the reuse of the grids AG and G in different screens and 

25 different arrangements, in which they will be able to find each other through the specification of 

26 selected ivar matching. Ivars 180can make the entities 66 reusable. 
27 

28 Again referring to Figure 10, in specification of the entity 176 that publishes the ivar 

29 180a, the ivar 180a can be linked to an ivar 180b published by the other entity 178, perhaps one 

30 on the same screen 168. Accordingly, the Navigatorl76 and the Record 178 on the same screen 

43 



1 168 can be linked by their 'rowid' ivars 180a,b respectively. This linking can be done by 

2 specifying a matchlist 181 on one or both of the entities 177,178 recorded in the table 166 of the 

3 file 38. For example, the screen 168 with ID 'exampscreen' with two children; the Navigator 

4 176 with ED c nav-one' and the Record 178 with ED 'rec-two' is recorded in the table 166. Each 

5 of the children 176, 178 exports the respective ivar 180a,b called 'rowid'. The two 180a,b by 

6 placing the following code in the nav-one entity of Table 166: 
7 

. 8 <param name- TVars">rowid= parent.rec-two.ro wid </param>. 
9 

10 Accordingly, in the run-time application platform 30, the entity .main#l .exampscreen#5.nav- 

1 1 one#12 with matchlist 181 'rowid = parent.rec-two.rowid' would link 

^12 main#l.exampscreen#5.nav-one# 12. rowed to match the ivar .main#l.exampscreen#5.rec- 

<1B two#12.rowid. It should be noted that the 'rowid =' part of the matchlist 181 refers to the ivar 
CO 

4^4 180a named 'rowid' in the nav-one en-tity. The 'parent' in the matchlist 181 is used to go up the 

M5 respective hierarchy by one level. Furthermore, multiple parent tags could also be implemented 

OJS in a more complex hierarchy, as in 'rowid^arent.parent.otherscreen.othernav.rowid'. In 

,17 addition, it is possible to have multiple entities that all match a given ivar matchlist 1 81 . If this 

■Ik occurs, the ivar 1 80 will link up with ALL matching ivars 1 80, which would have the effect of 

\Ji 

\W linking the ivars 180 of two widgets 60 previously separated. It is also possible to specify 

i i i 

|2j0 multiple matches in the same matchlist 181 for one entity 66, by separating them with commas: 

H\ <param name-TV ars">rowid=parent.rec-two.rowid, rowid=parent.parent.grid.rowid, 

22 datafield=childname.rowid </param>. It should be noted that the ivar matchlist 181 can use 

23 relative paths or absolute paths. 
24 

25 In the XML language notation of file 38, the Ivars 180 can be created by calling 

26 initIvar(String name, String matchlist). The name is the fully qualified name of the ivar 180, and 

27 matchlist 1 8 1 is the matchlist of the entity 66 publishing the respective ivar 1 80. Initlvar is 

28 usually called in an entity constructor. Ivars 1 80 can be set with setlVar or get their values with 

29 getlVar. In addition, in the event that your ivar 180 gets changed by another device 18, the 
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1 corresponding widget 60 implements a IvarReceiver to register as a listener, thereby receiving 

2 notification of the change. Preferably, all the links 70 are bi-directional and independent of 

3 creation order. Types of ivars 180 can include Temporary Ivars which are associated with a 

4 particular device 18 session. The device 18 can set the temporary ivar, like setting a variable, 

5 which is then available for the device 18 throughout for the session. Accordingly, when the 

6 device 18 logs out or times out, the temporary ivars the device 18 created are destroyed. 

7 Permanent Ivars are associated with a database 20a,b. When a permanent ivar is set, it is stored 

8 in the database 20a,b, thus it is not destroyed when the device 18 logs out or times out (i.e. it is 

9 persistent. Server Ivars cannot be set by the device 18, rather they can only be retrieved. 
10 

11 Example Entities and Relationships 

12 The application 30 is built out of entities 66 - objects such as grids, tables, groups, 

Q 

$B queries, and screens, which are combined by relationships 70. For example, a screen with a table 

I"! 

\l% and a grid in it. Each relationship 70 consists of a "parent" and a "child" entity 66. 

IK6 For entity 66 naming, as the generated application 30 runs, it creates various screens, 

ffl 

yi which contain widgets 60 and other screens, generating a hierarchy of widgets 60. Each of these 

jfls widgets 60 must have a unique name in order to be unambiguously referenced. Each entity 66 in 

\W the file 38 has a unique ED, but lacks the ability to specify names for objects in a run-time system 
M 

j2p 10. We could have multiple instantiations of a single entity 66 and those instances could occur in 

!2'1 different locations on the hierarchy of entities 66. Run-time entities 66, thus, are assigned unique 

22 names that can look something like: .main#l.subscreen#5.samplegrid#12. The name of the 

23 widget 60 is preferably determined by taking its ID, adding '#' and a unique number, then 

24 appending that to the name of its parent. This facilitates determination at a glance both the entity 

25 66 ID and ancestry of a run-time object. The name .main#l .subscreen#5.samplegrid#12 can be 

26 broken down into the main application 30 entity 66 with ID 'main' and run-time name .main#l . 

27 It has a child which is a screen, with ID 'subscreen' and run- time name .main#l.subscreen#5, 

28 and itself has the grid with ID 'samplegrid' as a child. 
29 
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1 In regards to Ivar 1 80 naming, many widgets 60 (generally the ones which access data) 

2 publish Ivars 180. For instance, a Grid widget 60 will publish a rowid Ivar 180, which contains 

3 the rowid of the currently selected row in that grid and also publish one Ivar 180 for each 

4 column, containing data for the currently selected row in that column. Thus a grid called: 

5 .main#l .subscreen#5.samplegrid#12 would publish the ivar 

6 .main#l.subscreen#5.samplegrid#12.rowid. 
7 

8 Some common features exist across entities 66. Each entity 66 supports a security 

9 parameter 56. This disables the entity 66 (requires permanently) if the correct permissions 

1 0 condition is not met, or an ivar 180 equality is not met. 

1 1 There can be two main types of required parameters: overloadable parameters (O-params) 

12 and a complete set of all parameters (A-params), as given with examples in the sample entities 

P 

© 66 listed below. Over-loadable parameters can be changed depending on where the entity is 
reused. 

$,6 Each application 30 generated by the generator 42 can have one top-level entity 66. 

fif V The top-level entity 66 is of type Application and is never used as the "child" part of a 

5! 

flfS relationship 70. 

j|j9 'Application' Entities 

HO Contained by: TOPLEVEL 

n 

s^l Contains: Any 

22 A-param: Id, name, appname, querysystem, delay, servername 

23 O-param: None 

24 The meaning of the parameters for these top level entities 66 are defined as: 

25 name - Displayed title of the main window of the application; 

26 appname - Name of the application; 

27 querysystem -The system for querying the database; 

28 delay - The delay between automatic refreshes of data; and 

29 servername - The name of the server containing the database. 

30 As a top-level entity 66, an Application entity 66 can't use Require or Conflict or have any 

31 security. It always gets created. Application entities 66 log the user 18 in as guest by default. 
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1 The user id ivar 180 is initialized to "guest" and the password ivar 180 is initialized to a null 

2 string. 
3 

4 Containers are entities 66 that visually contain other ones. Nearly all entities 66 can 

5 have children created in the relationships 70 table, but the children of a Grid, for example, are 

6 treated specially. On the other hand, Container Entities 66 can be used purely for layout purposes 

7 and don't change the way child entities 66 work. Since containers 66 can enclose other 

8 containers 66, you can nest them until your application 30 looks as desired in a predetermined 

9 manner. 
10 

1 1 'Screen' Entities 66 

12 Contained by: Container, Table 
Contains: Any 

Ift A-param: Speedkey, name, require, delay, popup, security 

h1|5 O-param: None 

!16 The meaning of the parameters for these top level entities 66 are defined as: 

ip7 name - Reference use; 

Si 

lifi delay - Used to set a refresh delay timer; 

m 

19 popup - Test used for popup tooltiptext in button widget 60 for when the entity 66 called as an 

I2D applet; and 

n 

1^1 security - Check for security. 

22 A Screen is a top-level window in the application 30. If the Screen is used as a child of any 

23 container object, it will be displayed as a button that you can click on to expose the new screen. 
24 

25 In a web interface 18, a screen can usually define a single generated HTML page. 

26 'Group' Entities 

27 Contained by: Container, Table 

28 Contains: Any 

29 A-param: Id, name 

30 O-param: None 

3 1 The meaning of the parameters for these top level entities 66 are defined as: 

47 



1 Name - Name of the group. 

2 The Group is a rectangle that contains other objects. You can use it to tweak the layout of your 

3 entities 66 in the current window. If the Group entity 66 has a occupied "name" field, then it 

4 appears as a visible frame with a subtitle. Otherwise, the group itself is completely invisible and 

5 only its child widgets 60 can be seen. 
6 

7 Middle tier 26 Entities 66 

8 Contained by: Application, Screen 

9 Contains: Query 

10 A-param: Id, name 

1 1 O -par am: 

12 The Middle tier Entity 66 class is currently used in generation of the sub-application 34 for the 
#3 middle tier 26 and so is a parent to all labels and fields in the application 30. 

f 

h ih Database Entities 66 

13(35 Contained by: Application 

j7 Contains: Table 

A-param: Id, name 

j*0 O -par am: 

jj^jo The Database Entity 66 class is used in generation of the sub-application 32 for the end tier 16 

H'\ and so is a parent to all tables and fields in the application 30. 

22 

23 'TabSet' Entities 

24 Contained by: Container 

25 Contains: Any 

26 A-param: Require, name, id, security, row, column, fill, anchor 

27 O-param: Row, column, fill, anchor 

28 The meaning of the parameter for these tabset container entities 66 are defined as: 

29 name - For reference use. 

30 A TabSet entity 66 can appear using a "notebook tab" type of display. With a note-book, 
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1 you can click on a tab at the top of a window and change what is currently displayed. 

2 A tabset 66 preferably should have only screen as children. 
3 

4 Read-only Entities 66 can be represented by 

5 'Report' Entities 

6 Contained by: Container 

7 Contains: None 

8 A-param: Id, appname, name, file, width, height, code, require, row, column, 

9 fill, anchor 

10 O-param: Row, column, fill, anchor 

1 1 The meaning of the parameter for these tabset container entities 66 are defined as: 

12 name - For reference use; 

pi 

^3 appname - Name of the Entity. Used in superclass JavaReport.java; 

file - Name of file assosiated with the Entity Code Additional code supplied; 

*]jj;j5 fill - Used for Layout Constraints; 

Lj, 

j|16 row - Used for Layout Constraints; 

QV column - Used for Layout Constraints; and 

EI 

j;lj8 anchor - Used for Layout Constraints. 

With the introduction of squery, the file 38 could also be useful for updating the database 20a,b 

{■lb 

($0 ("scripted transactions"). In the accounting application, we might use it to post a batch of 



22 A Report entity in the appgenerator 42 is used as the child of a Screen, Group, or Tab when it 

23 appears as a pushbutton. 

24 The application 30 requests a report from the query system by name; and 

25 The query system then returns the display XML which is converted by the end user application 

26 30 into something displayed on-screen of the device 18. 

27 Another read only entity 66 is the 'HTML' Entities. 

28 Contained by: Container 

29 Contains: Any 

30 A-param: Name, id, include, security, align, border, code 

31 O-param: Height, width, row, column, rowspan, columnspan, fill, anchor 




transactions. Reports work (or should work) like this: 




1 The meaning of the parameters for these read only entities 66 are defined as: 

2 name - Name of the entity; 

3 include - Contains path and filename of HTML document to be included in the application; 

4 border - Sets the border of the HTML displayed on the page, if border is omitted, default border 

5 isO; 

6 alignment - Alignment of the HTML, if alignment is omitted, de- fault alignment is left; and 

7 code - Contains HTML code to be displayed in the application. 

8 An HTML object allows you to write your own HTML code, but only in JSP mode. 
9 

10 Another read only entity 66 is 'Calc Box' Entities. 

1 1 Contained by: Container 

12 Contains: None 

O 

d!3 A-param: Id, name, label, mode, require 

4Jl O-param: Row, column, fill, anchor, Ivars 

to The meaning of the parameters for these read only entities 66 are defined as: 

huh 

it$ name - Name for the box; 

'iV label - Label on the box; 

HI 3 

j|j8 mode - One of 'text' or 'password', used with WAP applications; and 

^li9 Ivars - as described above. 

1 3 j 

j2p Calcbox entities 66 can be used as a way for the user 18 to view data in i-variables. 

22 Another read only entitiy 66 is 'Image 5 Entities. 

23 Contained by: Container, Table 

24 Contains: None 

25 A-param: Id, name, image, popup, require, messagetype, target, wapimage 

26 O-param: Popup, messagetype, require, target 

27 The meaning of the parameters for these read only entities 66 are defined as: 

28 name - Name of entity; 

29 image - Filename of image to be displayed; 

30 popup - Text displayed when mouse is dragged over image; 
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1 messagetype, target - Message is sent out to target when a mouse is dragged over image, these 

2 two param-eters are dependent on one another, hence must be used together; and 

3 wapimage - Contains filename of image, (used in WAP mode). 

4 An Image entity 66 displays the image filename given in its param field. 
5 

6 

7 Further read only entities 66 are 'Label' Entities. 

8 Contained by: Container 

9 Contains: None 

10 A-param: Name, id, require 

1 1 O -param: Row, column, rowspan, columnspan, fill, anchor 

12 The meaning of the parameters for these read only entities 66 are defined as: 
4'S Name -Caption of the label. 

m 

i X£ A Label object simply displays the text in its name field when it's used. Sometimes labels can be 

a l s 5 useful with security; for example, to display an "Access Denied" message when opening up a 

Wb window. In the opposite case, to display a Group container that has useful information when 

m 

17 access is allowed. 



m 

li9 Another type of entity 66 is a Navigation Entity. 



'SpeedNav' Entity 

21 Contained by: Container 

22 Contains: Any 

23 A-param: Id, name, require, parent, child, type 

24 O-param: None 

25 The meaning of the parameters for these read only entities 66 are defined as: 

26 name - For reference use; and 

27 type - Used to select style for HTML generation. 

28 It corresponds to the menubar at the top of a window. The SpeedNav entity 66 can be used in the 

29 application 30, and can also be used as the standard navigator for that application 30. By default, 

30 SpeedNav can display all items in application. 
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2 A further navigation entity 66 is 'SpeedMenu' Entity. 

3 Contained by: SpeedNav 

4 Contains: Any 

5 A-param: Speedkey, name 

6 O-param: None 

7 The meaning of the parameters for these read only entities 66 are defined as: 

8 name - Name; and 

9 Speedkey - Key used to select. 
10 

11 A further navigation entity 66 is 'Graph' Entity. 

12 Contained by: Container 
=13 Contains: Any 

m 

0$ A-params: Id, name, label, parent, child 

O-params: Ivars, row, column, rowspan, columnspan, anchor, fill 

$35 The meaning of the parameters for these read only entities 66 are defined as: 

]I V name - Not normally used with Graphs; 

label - Field name of label column; 

m 

\W parent - Field name of parent column; and 

M 

|2p child - Field name of child column. 

I2'l A visual entity 66 that displays the parent - child relationship in a cyclical manner, quite similar 

22 to navigators. Used in the Application Editor 46 to show entities 66 and relations 70. 

23 

24 A further type of entities 66 is Entities for User Input. The file 38 can accept user 18 

25 input in three ways: the user 18 can click on Screen buttons, Notebook tabs (Tab entities), or on a 

26 SpeedNav entity 66 to open and close windows and move through the application 30; Record 

27 and Grid entities 66 allow the user 18 to edit data in SQL databases; and Input boxes allow the 

28 user 18 to enter data into input lines that are stored in i-vars 180. These can then be used in SQL 

29 queries or Require/Conflict entities to control the application's 30 behaviour. 
30 

3 1 One user input entity 66 type is 'Preview' Entities. 
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1 Contained by: Any 

2 Contains: Query 

3 A-param: Id, require 

4 O-param: Ivars, row, column, rowspan, columnspan, anchor, fill 

5 The meaning of the parameters for these read only entities 66 are defined as: 

6 Ivars - see above description. 

7 The Preview entity 66 is used to preview other entities 66. The preview entity 66 is available for 

8 the applet portion and is currently used in the generator 42. 
9 

10 Another user input entity 66 is 'Login' Entity. 

1 1 Contained by: Container 

12 Contains: None 

O 

13 A-param: Id, name, popup, require 

QJ 

£| O-param: Row, column, fill, anchor, rowspan, columspan, Ivars 

Jt5 The meaning of the parameters for these read only entities 66 are defined as: 

if 6 name - Caption of button to be created; and 

i!P 

17 popup - Text displayed when cursor lingers over entity. 
Creates, login or logout buttons. 

m 
\w 

|2|o Another input entity 66 is 'Table' Entities. 

ISfl Contained by: Container 

22 Contains: Any 

23 A-param: Name, data, order, side, tables 

24 O-param: Order, side, tables 

25 The meaning of the parameters for these read only entities 66 are defined as:name - For reference 

26 use; 

27 data - Data to fill in the table; 

28 order - Not implemented; 

29 side - Left or right in join; and 

30 Tables - Alias. 
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1 These entities 66 Publishes: Stable, $recno($table), Stable. handle,$table. [fieldnames]. The Table 

2 entity refers to an SQL table named after the entity's shortname. If an SQL table is called "frogs" 

3 with fields "name", "age", "arms" and "legs", you will create an entity of type Table with a 

4 shortname of "frogs". Under it, you would attach Field entities with shortnames of "name", 

5 "age", and so on. The appgenerator 42 does a search for all Table entities when it builds the 

6 application 30, and makes sure all the appropriate SQL tables exist and contain the right fields. 

7 The SQL table in the database 20a,b also has an additional magic field, handle, that acts as the 

8 table's primary key. All database access routines in the file 38 preferably depend on this primary 

9 key. 
10 

1 1 Another user input entity 66 is the 'CustomTable' Entity. 

12 Contained by: Container 

a 

i!8 Contains: Any 

I A-params: Name, data 

■§5 O-params: None 

Ifp If you need to use the system 12 to access, for example, a legacy Fortran app with an encrypted 

4V back-end, you can write your own Table abstraction 148. CustomTableBase 154 exists as a 

C1J8 bridge between the application 30 and the data source 20a,b. It implements the methods in the 

|Ji9 AbstractTable 162, as described above. 

Q 

I'M Another user input entity 66 is the 'Record' Entities. 

22 Contained by: Container 

23 Contains: Query 

24 A-param: Id, name, popup, require, Ivars, child, row, column, fill, anchor 

25 O-param: Ivars, row, column, fill, anchor 

26 The meaning of the parameters for these user input entities 66 are defined as: 

27 id - For reference use; 

28 name - For reference use; 

29 popup - Used for mouseOverStr in superclass JavaWidget; 

30 Ivars - see above description; 
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1 child - Used for Ivars 1 80; 

2 fill - Used for Layout Constraints; 

3 row - Used for Layout Constraints; 

4 column - Used for Layout Constraints; and 

5 anchor - Used for Layout Constraints. 

6 Record entities 66 are also used as part of the main application 30 to provide an entry form for 

7 data into an SQL table. Tables have the notion of a "current record number" (stored in the Ivar 

8 rowid) and they display all records from the table in the database 20a,b. The record entry form 

9 contains input fields taken directly from the table (Field entities), as well as CalcField entities 

10 that produce read-only values from SQL queries. To help communication between the Table 

1 1 entity, its Fields and CalcFields, the Table also publishes an Ivar 1 80 called Stable (the 

12 shortname of the current Table entity) and a set of Ivars 180 called Stable.FIELDNAME (one 



j2p A-param: Id, name, filename 

fel O-param: None 

22 The meaning of the parameters for these user input entities 66 are defined as: 

23 Name - Reference use; and 

24 Filename - Filename used for output file for the superclass Recorder. 

25 This Entity 66 is in charge of the Recorder component. The recorder is used to record the actions 

26 of the user 18. 
27 

28 Another input entity type 66 is 'Button' Entity. 

29 Contained by: Container 

30 Contains: Any 




Another input entity type 66 is 'Recorder' Entities. 
Contained by: Any 



for each field in the table). Field entities each read and write their respective 
$table.FIELDNAME Ivars 180 based on user 18 input. The Table entity 66 collects them and 
saves or loads them from the SQL table whenever the current record number is changed. 



Contains: None 




1 A-params: Name, id, label, messagetype, target, request, require 

2 O-params: Row, column, fill, anchor 

3 The meaning of the parameters for these user input entities 66 are defined as: 

4 name - Identifies the button. Not normally used with buttons; 

5 label - The label on the button; 

6 messagetype - The type of message that is to be sent. (i.e. Data, error...); 

7 target - The channel on which the message will be sent; and 

8 request - The value to give the message sent. 

9 Sends a message when pressed. This message will be interpreted by other entities 66 
10 to perform an action, (i.e. open a screen) 

11 

L2 Another input entity type 66 is 'Input Box 5 Entities. 

33 Contained by: Container 

£§ 

€f Contains: None 

1 ! 5 A-param: Id, name, label, hiddenlabel, datatype, mode, editable, require, 

ansa 

005 popup 

S.I I 

s 17 O-param: Row, column, fill, anchor, Ivars 

ijbfi The meaning of the parameters for these user input entities 66 are defined as: 

\ffl name - Used in the superclass JSPInputBox.java. (in JSP and Wap mode); 

| ij 

i20 label - The text that is to be displayed along with the InputBox; 

bil datatype - The type of data that the input box will be expecting, if this parameter is not specified, 

22 it will be equal to the value of the mode parameter, possible inputs: password, text, combo, 

23 boolean, char, varchar, image; 

24 popup - The text that is to be displayed when a mouse is dragged across the entity; 

25 editable - Determines whether the inputbox is editable or not, bydefault inputboxes are editable; 

26 and 

27 mode - Can be either text or password. 

28 Inputbox are used as a way for the user 18to enter data into Ivars 180. 
29 

30 Another input entity type 66 is 'Grid 5 Entities. 
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1 Contained by: Container 

2 Contains: Query 

3 A-params: Name, require, help 

4 O-params: Ivars, row, column, rowspan, columnspan, anchor, fill 

5 The meaning of the parameters for these user input entities 66 are defined as: 

6 name - Name of the grid. Not visible. 

7 A Grid entity 66 accesses SQL data in much the same way as a Table entity does, but it displays 

8 the data very differently. Instead of showing only one record at a time, a grid shows the data in a 

9 spreadsheet-like format with one record per row, and one field per column. Grids currently 

10 shows only Field and Calcfield entities that are its children. It also honours Require and Conflict 

1 1 entities that are parents of the Field enti-ties, so only the appropriate fields will be shown in the 



fcSl popup - The text that is displayed when mouse is dragged over the entity; 

22 label - Text displayed in list; 

23 parent - If parent is specified then you have a recursive navigator; and 

24 child - If only the child is specified it is a flat list. 

25 A Navigator entity 66 displays a hierarchical tree, generated from an SQL query, and changes 

26 the Ivar $rowid according to the currently selected item in the tree. This changes the current row 

27 displayed by the appropriate Table or Grid entity. A Navigator has a Query entity as one of its 

28 children, which provides the data for the tree. Furthermore, Navigator entities 66 can also act 

29 like most other entities 66, as they do not have to be children of 

30 Table or Grid entities 66. 



12 



grid. 




Another input entity type 66 is 'Navigator' Entities. 
Contained by: Container 
Contains: Query 

A-param: Id, name, popup, label, parent, child, require 

O-param: Row, column, fill, anchor, Ivars, rowspan, columnspan 

The meaning of the parameters for these user input entities 66 are defined as: 

name - Used as a title of the entity, (root of the tree); 
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1 

2 Another input entity type 66 is ' JavaAction' Entities. 

3 Contained by: Container 

4 Contains: None 

5 A-param: Id, name, popup, code 

6 O-param: 

7 The meaning of the parameters for these user input entities 66 are defined as 

8 name - Used as a label for the button corresponding to this entity 66; 

9 popup - Text is displayed when the mouse is dragged over the entity 66; and 

10 code - Java code that is to be executed during runtime. 

1 1 Allows you to execute Java code from within the xml file 38. The entity 66 is displayed as a 

12 button, which when pressed executes the code that is written in the file 38. 



22 SQL-based entry form. The "shortname" of the field entity 66 determines its I-variable name 

23 (which will be Stable.shortname) and the field name used in SQL. The "param" field is the SQL 

24 data type to use, which can be any data type supported by SQL or one of the magic data types 

25 "money", "phonenumber", or "password." A Field doesn't actually do SQL access itself; it 

26 merely sets an I-variable and expects its parent (a Table, Form, or indirectly, a Grid) to deal with 

27 loading or storing the value if necessary. If the Field has a Query as its child, the set of possible 

28 values is restricted to the data returned by the SQL query. The query is special and works like 

29 this: If it returns exactly two columns, then the first column is the data to store in the database, 

30 and the second column is the data to display for the user. For example, you could have 1 Blue 2 




Another input entity type 66 is 'Field' Entities. 
Contained by: Table 
Contains: Query 

A-params: Id, name, datatype, security 
O-params: None 

The meaning of the parameters for these user input entities 66 are defined as: 

name - Name of the field; and 

datatype - Type of data to be held in the field (i.e. int). 

A Field entity 66 is one field (also known as a column) in an SQL database, or a field in a non- 
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1 Red 3 Green and the field would display a drop-down box with the choices Blue, Red, and 

2 Green. If you selected Green, it would store '3' in the I-variable, which eventually gets written to 

3 the database. 
4 

5 Another input entity type 66 is 'CalcField' Entities. 

6 Contained by: Table 

7 Contains: WVEPS 

8 Publishes: Stable. [shortname] 

9 A-params: Id, name, code(to be added) 

10 O-params: None 

1 1 The meaning of the parameters for these user input entities 66 are defined as: 

12 name - Name for the field. 

4$ CalcFields can be used to represent aggregate functions in SQL such as SUM() and AUG(). 
14 

45 A further type of entities 66 are 'Invisible' Entities that Send or receive messages. 

'Publish' Entities 

17 Contained by: Application 

Contains: None 

m 

jjliP A-param: Id, name, value, Ivars 

|?|) O-param: 

124 The meaning of the parameters for these user input entities 66 are defined as: 

22 Ivars - Name of the Ivar to be published; and 

23 value - Value of the Ivar variable to be published. 

24 A Publish entity creates an Ivar 180 named after the entity's 66 shortname field, with the 

25 contents defined by its "param" field. Note that Table and Grid entities 66 also publish Ivars 180, 

26 but they are named something like "tablename.fieldname". There is no "tablename." in 

27 an Ivar 180 created by Publish, although you can simulate it by using something like "frogs. legs" 

28 as the shortname. Publish entities 66 aren't actually displayed anywhere in the generated appli- 

29 cation 30; they're invisible, but behave as if present. 
30 
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1 Another type of invisible entities 66 are 'Localization' Entities. 

2 Contained by: Application 

3 Contains: None 

4 A-param: 

5 O-param: 

6 Localization entity 66 allows you to display text in several different formats, according to the 

7 mapping selected. For example: <entity ID- 'localeTable" type="Localization"> 

8 <localization> 

9 <locale name="default"> 

10 <string refid='T'>A label</string> 

1 1 <string refid="2">A screen</string> 

1 2 <string refid="3">Popur Label</string> 
</locale> 

i'.-'i 

$jl <locale name="other"> 

£5 <string refid="l">A similar yet distinct label</string> 

jtj5 <string refid- '2">Le Screen</string> 

9V <string refid="3">ToolTip</string> 

Hi 

IX3S </locale> 

en 

</locahzation> 

jM) </entity> 

12.1 <entity ID="labelscreen" type="Screen"> 

22 <param name- 'name"xref>2</ref></param> 

23 <param name="popup"><ref>3</ref></param> 

24 <child name="applabel"></child> 

25 </entity> 

26 In this example the parameter name of the entity 66 screen (labelscreen) is referenced to 

27 "Screen". 
28 

29 Another type of invisible entity 66 is 'Neuron' Entities. 

30 Contained by: Container 
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1 Contains: Query 

2 A-param: Id, require, name, in, middle, out 

3 O-param: Row, column, fill, anchor 

4 The meaning of the parameters for these user input entities 66 are defined as: 

5 top - Parameter specifies channel on which neuron is listening; 

6 middle - Contains java code to be executed when neuron is fired; 

7 out- most applications 30 contain the tag. 

8 Neuron is a listener that listens to a channel specified in the 'in' parameter. When it receives the 

9 message it executes the Java code specified in the middle parameter. 
10 

1 1 Another invisible entity 66 is the 'Help' Entity. 

12 Contained by: Container 

O 

4$ Contains: Any 

Sl'l A-param: Id, name 
O-param: None 

Instantiates a help system. All entities 66 contained within the help entity should have a help 

17 parameter. 

h 

m 

\W Another invisible entity 66 is the 'Cursor' Entity, 

jlj) Contained by: Container 

fel Contains: None 

22 A-param: Id, name, require 

23 O-param: None 

24 The meaning of the parameters for these user input entities 66 are defined as: 

25 name - Name for cursor, not normally used. 

26 Is basically a record which has no visible parts. Cursor entities currently exist in JSP. 
27 

28 Another invisible entity 66 is the 'EntityCursor' Entity. 

29 Contained by: Container 

30 Contains: None 
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1 A-param: Id, name, require 

2 O -par am: None 

3 The meaning of the parameters for these user input entities 66 are defined as: 

4 name - Name for cursor, not normally used. 

5 This entity adds an Entity Cursor to the resultant app 30. This can/should only be done in the 

6 application editor 46. 
7 

8 Another invisible entity 66 is the 'XMLParsing' Entities. 

9 Contains: None 

10 An Entity 66 which takes XML input as string and Parses the XML code 38. 



jzp condition. 

iM QJoin entity 66 as a child of the query. The QJoin entity 66 requires two children, the left table, 

22 and the right table in the join. The two parameters required are: style(left, right, full) condition: 

23 which is what links the two tables together. I.e. tablel .name = table2.name The table 

24 relationships can have one parameter: tableas which defines an alias for the table, when joining a 

25 table with itself. 
26 

27 Another type of database query entity 66 is the 'QJoinRecursive' Entities. 

28 Contained by: Container 

29 Contains: Any 

30 A-param: Name, style, condition 
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12 Another type of entity are the Database Query Entities, or 'QJoin' Entities 




§]$ O-param: none 
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1 O-param: None 

2 The meaning of the parameters for these user input entities 66 are defined as: 

3 Name; 

4 Style; and 

5 condition. 

6 The recursive join option allows you to create extra rows which create additional rows in the 

7 result set to enumerate many possible parent child combinations. 

8 Another type of query entities 66 are 'Query' Entity. 

9 Contained by: Containers, Field Entity, Navigator Entity, Grid Entity, Record Entity 

10 Contains: None 

1 1 A-param: Id, name, where, group 

12 O-param: None 



Another type of query entity 66 is 'CustomQuery' Entity. 

22 Contained by: Container 

23 Contains: None 

24 A-param: Id, name, where, group, order 

25 O-param: None 

26 A custom Query is used depending on what kind of access to the datasource 20a,b you are using. 




The meaning of the parameters for these user input entities 66 are defined as: 

id - Reference use; 

where - Where Constraints; 

group - Group by clause; and 

order - Order by clause. 

This Entity corresponds to a SQL Query It is used in the following classes: QuertySet.java 
RequireQuery.java SQueryBase.java. 
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Another type of query entity 66 is'QueryBase' Entities. 
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Contains: None 



30 



An Entity 66 which is essentially a base form for the Query Entity. 



1 

2 

3 Accordingly, the above described sample entities 66 can be used with appropriate 

4 relationships 70 to control the presentation and functionability of widgets 60 on an interface 

5 screen 58 of the interface of the device 18, as well as provide operational behavior and structure 

6 to the components of the end tier 14 and middle tier 26 of the system 10. This integrated 

7 operational structure is supplied by the subprograms 32, 34, 36 of the application 30, which can 

8 be generated for a selected combination of hardware/software platforms in the tiers 14, 16, 26 

9 according to the file 38 parameters 40, 44, as processed by the generator 42. 
10 

1 1 Figure 1 1 shows example deployment configurations of the application 30 over the 

12 various tiers 14, 16, 26 of the system 10. For example, using the pass through 24 system of the 
%3 middle tier 26 facilitates the access of the devices 1 8 directly to inhouse data servers, low to 
8$ medium demand data driven websites, and low to medium cell phone data access. In addition, 

other example deployments could be through the EJB server 28a of the middle tier 26, thereby 

Jjlp facilitating access of the devices 18 for inhouse EJB systems, intranet applications, high demand 

0H7 data driven websites over the internet, and large volume cell phone data access. As well, middle 

it! 

AS tier technology 26 using the COM server 28b could be similar to that provided by the EJB server 

28a in deployment configuration. Furthermore, custom deployments using the custom queries 

$P 148 could be to interface various JAVA, web, or cell phone graphical user interfaces on the 

jj«a 

l21 various devices 18 to custom data stores 20a, b. 
22 

23 Referring to Figure 12, in operation of the application development system 12 the 

24 software developer constructs the abstract notation representation file 38 through input of the 

25 parameters 40, 44 at step 182. The file 38 is the declaration of all the various components to be 

26 found in the end application 30, such as but not limited to grids, records, screens, database 

27 queries, and database tables. These components or entities 66 are hooked or logically linked to 

28 one another through relationships 70, as described above, which is accomplished by a series of 

29 parent child relationships 70. Accordingly, the entity 66 can be reused through the relationships 

30 70, such as selecting an employer from a list and displaying relevant information in an 

31 accompanying grid. The input parameters can also be used to program custom business logic 
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1 using message based architecture, whereby the software developer can use the custom 

2 components of neurons to coordinate the acceptance, processing, and sending out of messages 

3 used during the access of the databases 20a, b from the devices 18 of the system 10. 

4 Furthermore, the parameters 40, 44 can be used to define custom reports to perform complex 

5 functions, whereby both the neurons and the reports can be made up of procedural XML. 

6 Furthermore, internationalized strings can be part of the input parameters 40, 44 to include the 

7 addition of functionality in multiple languages, such as using English and French labels, such as 

8 using the example XML code below. 
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Example XML 

01 <entity ID="localeTable" type="Localization"> 

02 <localization> 

03 <locale name= M english lf > 

04 <string refid="100">Manage Exchanges</string> 

05 <string refid= f, 101">Active Exchanges</string> 

06 <string refid= n 102">Manage Hardware</string> 

07 <string refid= M 103">Manage Hardware</string> 

08 <string refid="104">Status for Exchange</string> 

09 <string refid="105">Test Device</string> 

10 </locale> 

11 <locale name="french"> 

12 <string refid="100">Controlez les Echanges</string> 

13 <string refid="101">Les Echanges Actifs</string> 

14 <string refid= ,, 102 ,t >Manage Hardware</string> 

15 <string refid="103">Controlent Le Materiel</string> 

16 <string refid=" 1 04">Status de TEchange</string> 

17 <string refid="105">Test l'Appareil</string> 

18 </locale> 

19 </localization> 

20 </entity> 



Accordingly, the example code contains the definition of labels to be used by the graphical user 
interface of the device 18, wherein lines 3 through 10 enclose the definition of English labels 
while lines 11 through 18 enclose the definition of French labels. 
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1 Referring to Figure 12, the file 38 is then read into the application generator 42 and the 

2 XML description is parsed at step 184 and its syntax is validated through the checking of errors. 

3 The next step at 186 is to construct an inmemory representation of the input file 38 by the 

4 generator 42, whereby each target language of the file 38 is represented by an object. At the 

5 entity iterator stage 188, the generator 42 accesses each individual entities 66 code in the 

6 memory model to generate code for each and every object, which is used to generate individual 

7 language stubs or platform indicator for the beginning and end of the program 30, as well as 

8 processing the corresponding XML description 38 to facilitate generation of application sub- 

9 programs 32, 34, 36 for the corresponding target languages or platforms selected. This process is 

10 used in conjunction with the parameters 40, 44 for the selection of the corresponding tier at step 

11 190 and the selection of corresponding tier target language at step 192. Accordingly, each object 

12 type in the inmemory model of step 186 has a group of corresponding entities which are used to 

H 

13 define the code to be generated for the corresponding entity group in the selected platforms. 
Furthermore, the parameters of the entity 66 are parsed and interpreted at step 194 and then the 

dp output code is generated at step 196 for a selected tier output file 32 by which the central 

fjij5 platform application 30 is generated. The abstract notation form of the data contained in the file 

'$7 38 is thereby transformed to selected language or platform notation as determined by the input 

il 

|3|3S parameter 40, 44 and stubs. Accordingly, the next series or entity group represented by the next 

jl9 language or platform stub, positioned by the target language object, at the beginning and end of 

S2ft the entity group is processed by the entity iterator 188 through the above mentioned steps 190, 

|21 192, 194, 196 to output the output file 34 for the next tier platform. The entity iterator 188 

22 process continues until all of the output files have been generated for the selected number of tiers 

23 14, 16, 26 (and others if desired) to complete the central application platform 30. Accordingly, 

24 the output 30 is a series of source files 32, 34, 36 split across the tiers 14, 16, 26 of the 

25 application 30, which can be compiled on specified target platforms that may or may not be in 

26 the same language or on the same platform or machine. Furthermore, it should be noted that the 

27 source code of the application 30 can be generated at the time of program building is set up once 

28 per end user access. Therefore, the development system 12 facilitates the output of a series of 

29 programs 32, 34, 36 each of which potentially executes in a different language or on a different 

30 machine which corresponds to a distributed n-tier application platform 30. The system 12 can 
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1 give auto generation of the application 30 for different platforms, much as but not limited to 

2 JAVA, Tel, Php, C, their middle tier 26 components COM 28b, EJB 28a, and their final 

3 database schemas 20a, b. 
4 

5 Referring to Figure 13, further embodiment of the system 12 can include a computer 

6 system 200 comprising a processor 202 coupled to a storage medium 204 and memory 206. The 

7 processor 202 monitors the download or transfer of the description file module 208, the editor 

8 module 210, and the input module 212 to be used to generate the application file 30. The 

9 processor is also coupled to a display 214, which can be used by the software designer to 

10 coordinate the generation of the file 30. An input device 216, such as a keyboard, a mouse, or a 

1 1 voice activated device can be used to input data and other commands into the processor 202 to 

12 facilitate in the generation of the file 30. Furthermore, the display 214 could be touch sensitive 
P 

45 f° r use as 311 input device 216. A computer readable storage medium 204 is coupled to the 

l|t processor 202 for providing an operating system or the software of the other modules 208, 210, 

i3> 212 to the computer 200. The storage medium 204 could also represent downloaded data 

$6 accessed over a network. The computer readable medium 204 can include hardware and/or 

17 software, such as by way of example only, magnetic discs, magnetic tape, optically readable 

media, such as CD ROMs, and semi conductor memory, such as PCMCIA cards. In each case, 

\W the medium 204 may take the form of a portable item such as a small disc, floppy diskette, 

% cassette, or may take the form of a relatively large or immobile item such as a hard disk drive, a 

f2'l solid state memory card, or RAM provided in the computer system 200. It should be noted that 

22 the above listed example mediums 204 can be used either alone or in combination. Accordingly, 

23 the operation of the system 12 can be provided by software containing the above system 12 

24 features as software modules. 
25 

26 Although the system 10 and 12 have been described with reference to certain specific 

27 embodiments, various modifications thereof will be apparent to those skilled in the art without 

28 departing from the spirit and scope of the invention as outlined in the claims appended hereto. 
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